[ResponseOps] Granular Connector RBAC - adding back UIs for testing connectors in stack management #204804
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
doakalexi
changed the title
1 task
doakalexi
added
Team:ResponseOps
Contributor
|
Pinging @elastic/response-ops (Team:ResponseOps) |
paul-tavares
approved these changes
Dec 19, 2024
Contributor
paul-tavares
left a comment
paul-tavares
left a comment
There was a problem hiding this comment.
LGTM - Thank you.
FYI: I will likely be updating these in a future PR to mirror what I did for Microsoft Defender connector (new) - see screen capture here
js-jankisalvi
approved these changes
Jan 2, 2025
Contributor
js-jankisalvi
left a comment
js-jankisalvi
left a comment
There was a problem hiding this comment.
Tested locally and works as expected
pmuellr
approved these changes
Jan 3, 2025
Member
pmuellr
left a comment
pmuellr
left a comment
There was a problem hiding this comment.
LGTM
Tested with https://webhook.site , worked as expected.
Contributor
💚 Build Succeeded
Metrics [docs]Async chunks
Unknown metric groupsESLint disabled line counts
Total ESLint disabled count
History
|
doakalexi
added a commit
that referenced
this pull request
Jan 6, 2025
Part of #180908 ## Summary **EDR Connector Subfeature Privilege** This PR creates a new EDR connector sub-feature privilege under the read privilege for connectors. The read privilege currently allows users to execute connectors, and this new privilege will limit some of the connectors that can be executed. When the EDR privilege is turned on, users will be able to execute EDR connectors, and when it is off they will not execute. This new privilege includes SentinelOne and Crowdstrike connectors. To determine which connectors are considered EDR connectors, we leverage`getKibanaPrivileges` in the connector type definition. I removed the restrictions to use this field only for system actions and renamed `getSystemActionKibanaPrivileges` to `getActionKibanaPrivileges`. I also added a field, `subFeatureType `, to the connector type definition to help disable testing/executing an connectors that are restricted under a sub-feature. **EDR Connector Execution for Testing** The execution of EDR connectors using the API is limited to a single sub-action for testing purposes. This ensures users can still configure/test EDR connectors. In a separate [PR](#204804), I added back the SentinelOne and Crowdstrike params UIs with options restricted to one sub-action. **Rule API and Feature Configuration Updates** Validation has been added to the rule APIs to enforce restrictions on adding EDR connectors. The connector feature configuration has been updated to include a new feature ID, EdrForSecurityFeature, which ensures that EDR connectors are hidden on the rule form. Note: I saw that EDR connectors are also temporarily restricted in the Security Solution UI. To streamline this, I removed the `isBidirectionalConnectorType` check in `action_type_registry.ts`. Instead, I removed `SecurityConnectorFeatureId` from the `supportedFeatureIds` of the SentinelOne connector type definition. ### Checklist Check the PR satisfies following conditions. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ## To test **EDR Connector Subfeature Privilege** 1. Create a new role and disable EDR connectors under the Actions and Connectors privilege 2. Create a new user and assign that role to user 3. Create a Sentinel One connector (It doesn't need to work, you can use fake values for the url and token) 4. Login as the new user and run the following in Dev Tools to verify that you aren't authorized execute the Sentinel One connector ``` POST kbn:/api/actions/connector/$CONNECTOR_ID/_execute { "params": { "subAction": "getAgents", "subActionParams": {} } } ``` 7. Update the role to enable EDR connectors and repeat the steps to verify that you are authorized to run the connector. (It will fail but verify it's not Unauthorized) **EDR Connector Execution for Testing** 1. Enable the EDR connectors privilege in the role you created above and log in as the user you created above. 2. Run the following in Dev Tools to verify that you are authorized execute the Sentinel One connector using only the `getAgents` sub-action. (It will fail but verify it's not `Unauthorized`) ``` POST kbn:/api/actions/connector/$CONNECTOR_ID/_execute { "params": { "subAction": "getAgents", "subActionParams": {} } } ``` 3. Run it again but replace the `subAction` with `isolateHost`. Verify that you get an unauthorized error. **Rule API and Feature Configuration Updates** 1. 1. Enable the EDR connectors privilege in the role you created above and log in as the user you created above. 2. Go to Stack Management 3. Try to create a rule, and verify that you don't see the SentinelOne connector. 4. Try to create a rule using the API and add your SentinelOne connector, verify that the API throws an error. ``` POST kbn:/api/alerting/rule { "tags": [], "params": {}, "schedule": { "interval": "1m" }, "consumer": "alerts", "name": "Always firing rule", "rule_type_id": "example.always-firing", "actions": [ { "group": "small", "id": "$CONNECTOR_ID", "params": { "subAction": "isolateAgent", "subActionParams": {} }, "frequency": { "notify_when": "onActionGroupChange", "throttle": null, "summary": false } } ], "alert_delay": { "active": 1 } } ``` 5. You can test the same behaviors when trying to add a SentinelOne connector to existing rules. --------- Co-authored-by: kibanamachine <[email protected]>
doakalexi
added a commit
to doakalexi/kibana
that referenced
this pull request
Jan 6, 2025
Part of elastic#180908 ## Summary **EDR Connector Subfeature Privilege** This PR creates a new EDR connector sub-feature privilege under the read privilege for connectors. The read privilege currently allows users to execute connectors, and this new privilege will limit some of the connectors that can be executed. When the EDR privilege is turned on, users will be able to execute EDR connectors, and when it is off they will not execute. This new privilege includes SentinelOne and Crowdstrike connectors. To determine which connectors are considered EDR connectors, we leverage`getKibanaPrivileges` in the connector type definition. I removed the restrictions to use this field only for system actions and renamed `getSystemActionKibanaPrivileges` to `getActionKibanaPrivileges`. I also added a field, `subFeatureType `, to the connector type definition to help disable testing/executing an connectors that are restricted under a sub-feature. **EDR Connector Execution for Testing** The execution of EDR connectors using the API is limited to a single sub-action for testing purposes. This ensures users can still configure/test EDR connectors. In a separate [PR](elastic#204804), I added back the SentinelOne and Crowdstrike params UIs with options restricted to one sub-action. **Rule API and Feature Configuration Updates** Validation has been added to the rule APIs to enforce restrictions on adding EDR connectors. The connector feature configuration has been updated to include a new feature ID, EdrForSecurityFeature, which ensures that EDR connectors are hidden on the rule form. Note: I saw that EDR connectors are also temporarily restricted in the Security Solution UI. To streamline this, I removed the `isBidirectionalConnectorType` check in `action_type_registry.ts`. Instead, I removed `SecurityConnectorFeatureId` from the `supportedFeatureIds` of the SentinelOne connector type definition. ### Checklist Check the PR satisfies following conditions. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ## To test **EDR Connector Subfeature Privilege** 1. Create a new role and disable EDR connectors under the Actions and Connectors privilege 2. Create a new user and assign that role to user 3. Create a Sentinel One connector (It doesn't need to work, you can use fake values for the url and token) 4. Login as the new user and run the following in Dev Tools to verify that you aren't authorized execute the Sentinel One connector ``` POST kbn:/api/actions/connector/$CONNECTOR_ID/_execute { "params": { "subAction": "getAgents", "subActionParams": {} } } ``` 7. Update the role to enable EDR connectors and repeat the steps to verify that you are authorized to run the connector. (It will fail but verify it's not Unauthorized) **EDR Connector Execution for Testing** 1. Enable the EDR connectors privilege in the role you created above and log in as the user you created above. 2. Run the following in Dev Tools to verify that you are authorized execute the Sentinel One connector using only the `getAgents` sub-action. (It will fail but verify it's not `Unauthorized`) ``` POST kbn:/api/actions/connector/$CONNECTOR_ID/_execute { "params": { "subAction": "getAgents", "subActionParams": {} } } ``` 3. Run it again but replace the `subAction` with `isolateHost`. Verify that you get an unauthorized error. **Rule API and Feature Configuration Updates** 1. 1. Enable the EDR connectors privilege in the role you created above and log in as the user you created above. 2. Go to Stack Management 3. Try to create a rule, and verify that you don't see the SentinelOne connector. 4. Try to create a rule using the API and add your SentinelOne connector, verify that the API throws an error. ``` POST kbn:/api/alerting/rule { "tags": [], "params": {}, "schedule": { "interval": "1m" }, "consumer": "alerts", "name": "Always firing rule", "rule_type_id": "example.always-firing", "actions": [ { "group": "small", "id": "$CONNECTOR_ID", "params": { "subAction": "isolateAgent", "subActionParams": {} }, "frequency": { "notify_when": "onActionGroupChange", "throttle": null, "summary": false } } ], "alert_delay": { "active": 1 } } ``` 5. You can test the same behaviors when trying to add a SentinelOne connector to existing rules. --------- Co-authored-by: kibanamachine <[email protected]> (cherry picked from commit 23a5c6d) # Conflicts: # x-pack/platform/plugins/shared/actions/server/application/connector/methods/execute/execute.ts # x-pack/platform/plugins/shared/actions/server/authorization/actions_authorization.test.ts # x-pack/platform/plugins/shared/actions/server/authorization/actions_authorization.ts
Contributor
|
Starting backport for target branches: 8.x https://github.com/elastic/kibana/actions/runs/12639007991 |
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Jan 6, 2025
…onnectors in stack management (elastic#204804) Part of elastic#180908 ## Summary As part of the changes for EDR Connector Execution for Testing, this PRs updates the SentinelOne and Crowdstrike params UIs to limit to a single sub-action. SentinelOne: <img width="861" alt="Screenshot 2024-12-18 at 11 16 49 AM" src="https://github.com/user-attachments/assets/1a839d21-7ba7-4c4e-b3e9-8772725fad63" /> Crowdstrike: <img width="855" alt="Screenshot 2024-12-18 at 11 17 01 AM" src="https://github.com/user-attachments/assets/b6c17964-8c49-4b5a-b1c7-bb4c6bb89621" /> ### Checklist Check the PR satisfies following conditions. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### To test 1. In Stack Management create SentinelOne and Crowdstrike connectors (They don't need to work, you can use fake values for the url and token) 2. Test the new connectors. Verify that you only see one action type and that it can't be changed and that the params are correctly sent in the request. (cherry picked from commit 99f5e32)
Contributor
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
doakalexi
added a commit
that referenced
this pull request
Jan 7, 2025
# Backport This will backport the following commits from `main` to `8.x`: - [[ResponseOps] Granular Connector RBAC (#203503)](#203503) <!--- Backport version: 8.9.8 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Alexi Doak","email":"[email protected]"},"sourceCommit":{"committedDate":"2025-01-06T18:53:35Z","message":"[ResponseOps] Granular Connector RBAC (#203503)\n\nPart of https://github.com/elastic/kibana/issues/180908\r\n\r\n## Summary\r\n\r\n**EDR Connector Subfeature Privilege**\r\nThis PR creates a new EDR connector sub-feature privilege under the read\r\nprivilege for connectors. The read privilege currently allows users to\r\nexecute connectors, and this new privilege will limit some of the\r\nconnectors that can be executed. When the EDR privilege is turned on,\r\nusers will be able to execute EDR connectors, and when it is off they\r\nwill not execute. This new privilege includes SentinelOne and\r\nCrowdstrike connectors.\r\n\r\nTo determine which connectors are considered EDR connectors, we\r\nleverage`getKibanaPrivileges` in the connector type definition. I\r\nremoved the restrictions to use this field only for system actions and\r\nrenamed `getSystemActionKibanaPrivileges` to\r\n`getActionKibanaPrivileges`. I also added a field, `subFeatureType `, to\r\nthe connector type definition to help disable testing/executing an\r\nconnectors that are restricted under a sub-feature.\r\n\r\n**EDR Connector Execution for Testing**\r\nThe execution of EDR connectors using the API is limited to a single\r\nsub-action for testing purposes. This ensures users can still\r\nconfigure/test EDR connectors. In a separate\r\n[PR](#204804), I added back the\r\nSentinelOne and Crowdstrike params UIs with options restricted to one\r\nsub-action.\r\n\r\n**Rule API and Feature Configuration Updates**\r\nValidation has been added to the rule APIs to enforce restrictions on\r\nadding EDR connectors. The connector feature configuration has been\r\nupdated to include a new feature ID, EdrForSecurityFeature, which\r\nensures that EDR connectors are hidden on the rule form.\r\nNote: I saw that EDR connectors are also temporarily restricted in the\r\nSecurity Solution UI. To streamline this, I removed the\r\n`isBidirectionalConnectorType` check in `action_type_registry.ts`.\r\nInstead, I removed `SecurityConnectorFeatureId` from the\r\n`supportedFeatureIds` of the SentinelOne connector type definition.\r\n\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\n- [ ] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n\r\n## To test\r\n\r\n**EDR Connector Subfeature Privilege**\r\n1. Create a new role and disable EDR connectors under the Actions and\r\nConnectors privilege\r\n2. Create a new user and assign that role to user\r\n3. Create a Sentinel One connector (It doesn't need to work, you can use\r\nfake values for the url and token)\r\n4. Login as the new user and run the following in Dev Tools to verify\r\nthat you aren't authorized execute the Sentinel One connector\r\n```\r\nPOST kbn:/api/actions/connector/$CONNECTOR_ID/_execute\r\n{\r\n \"params\": {\r\n \"subAction\": \"getAgents\",\r\n \"subActionParams\": {}\r\n }\r\n}\r\n```\r\n7. Update the role to enable EDR connectors and repeat the steps to\r\nverify that you are authorized to run the connector. (It will fail but\r\nverify it's not Unauthorized)\r\n\r\n**EDR Connector Execution for Testing**\r\n1. Enable the EDR connectors privilege in the role you created above and\r\nlog in as the user you created above.\r\n2. Run the following in Dev Tools to verify that you are authorized\r\nexecute the Sentinel One connector using only the `getAgents`\r\nsub-action. (It will fail but verify it's not `Unauthorized`)\r\n```\r\nPOST kbn:/api/actions/connector/$CONNECTOR_ID/_execute\r\n{\r\n \"params\": {\r\n \"subAction\": \"getAgents\",\r\n \"subActionParams\": {}\r\n }\r\n}\r\n```\r\n3. Run it again but replace the `subAction` with `isolateHost`. Verify\r\nthat you get an unauthorized error.\r\n\r\n**Rule API and Feature Configuration Updates**\r\n1. 1. Enable the EDR connectors privilege in the role you created above\r\nand log in as the user you created above.\r\n2. Go to Stack Management\r\n3. Try to create a rule, and verify that you don't see the SentinelOne\r\nconnector.\r\n4. Try to create a rule using the API and add your SentinelOne\r\nconnector, verify that the API throws an error.\r\n```\r\nPOST kbn:/api/alerting/rule\r\n{\r\n \"tags\": [],\r\n \"params\": {},\r\n \"schedule\": {\r\n \"interval\": \"1m\"\r\n },\r\n \"consumer\": \"alerts\",\r\n \"name\": \"Always firing rule\",\r\n \"rule_type_id\": \"example.always-firing\",\r\n \"actions\": [\r\n {\r\n \"group\": \"small\",\r\n \"id\": \"$CONNECTOR_ID\",\r\n \"params\": {\r\n \"subAction\": \"isolateAgent\",\r\n \"subActionParams\": {}\r\n },\r\n \"frequency\": {\r\n \"notify_when\": \"onActionGroupChange\",\r\n \"throttle\": null,\r\n \"summary\": false\r\n }\r\n }\r\n ],\r\n \"alert_delay\": {\r\n \"active\": 1\r\n }\r\n}\r\n```\r\n5. You can test the same behaviors when trying to add a SentinelOne\r\nconnector to existing rules.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <[email protected]>","sha":"23a5c6d2db1cd8d501e94c1af872d4ce7792e9ee","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","Team:Obs AI Assistant","v8.18.0"],"number":203503,"url":"https://github.com/elastic/kibana/pull/203503","mergeCommit":{"message":"[ResponseOps] Granular Connector RBAC (#203503)\n\nPart of https://github.com/elastic/kibana/issues/180908\r\n\r\n## Summary\r\n\r\n**EDR Connector Subfeature Privilege**\r\nThis PR creates a new EDR connector sub-feature privilege under the read\r\nprivilege for connectors. The read privilege currently allows users to\r\nexecute connectors, and this new privilege will limit some of the\r\nconnectors that can be executed. When the EDR privilege is turned on,\r\nusers will be able to execute EDR connectors, and when it is off they\r\nwill not execute. This new privilege includes SentinelOne and\r\nCrowdstrike connectors.\r\n\r\nTo determine which connectors are considered EDR connectors, we\r\nleverage`getKibanaPrivileges` in the connector type definition. I\r\nremoved the restrictions to use this field only for system actions and\r\nrenamed `getSystemActionKibanaPrivileges` to\r\n`getActionKibanaPrivileges`. I also added a field, `subFeatureType `, to\r\nthe connector type definition to help disable testing/executing an\r\nconnectors that are restricted under a sub-feature.\r\n\r\n**EDR Connector Execution for Testing**\r\nThe execution of EDR connectors using the API is limited to a single\r\nsub-action for testing purposes. This ensures users can still\r\nconfigure/test EDR connectors. In a separate\r\n[PR](#204804), I added back the\r\nSentinelOne and Crowdstrike params UIs with options restricted to one\r\nsub-action.\r\n\r\n**Rule API and Feature Configuration Updates**\r\nValidation has been added to the rule APIs to enforce restrictions on\r\nadding EDR connectors. The connector feature configuration has been\r\nupdated to include a new feature ID, EdrForSecurityFeature, which\r\nensures that EDR connectors are hidden on the rule form.\r\nNote: I saw that EDR connectors are also temporarily restricted in the\r\nSecurity Solution UI. To streamline this, I removed the\r\n`isBidirectionalConnectorType` check in `action_type_registry.ts`.\r\nInstead, I removed `SecurityConnectorFeatureId` from the\r\n`supportedFeatureIds` of the SentinelOne connector type definition.\r\n\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\n- [ ] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n\r\n## To test\r\n\r\n**EDR Connector Subfeature Privilege**\r\n1. Create a new role and disable EDR connectors under the Actions and\r\nConnectors privilege\r\n2. Create a new user and assign that role to user\r\n3. Create a Sentinel One connector (It doesn't need to work, you can use\r\nfake values for the url and token)\r\n4. Login as the new user and run the following in Dev Tools to verify\r\nthat you aren't authorized execute the Sentinel One connector\r\n```\r\nPOST kbn:/api/actions/connector/$CONNECTOR_ID/_execute\r\n{\r\n \"params\": {\r\n \"subAction\": \"getAgents\",\r\n \"subActionParams\": {}\r\n }\r\n}\r\n```\r\n7. Update the role to enable EDR connectors and repeat the steps to\r\nverify that you are authorized to run the connector. (It will fail but\r\nverify it's not Unauthorized)\r\n\r\n**EDR Connector Execution for Testing**\r\n1. Enable the EDR connectors privilege in the role you created above and\r\nlog in as the user you created above.\r\n2. Run the following in Dev Tools to verify that you are authorized\r\nexecute the Sentinel One connector using only the `getAgents`\r\nsub-action. (It will fail but verify it's not `Unauthorized`)\r\n```\r\nPOST kbn:/api/actions/connector/$CONNECTOR_ID/_execute\r\n{\r\n \"params\": {\r\n \"subAction\": \"getAgents\",\r\n \"subActionParams\": {}\r\n }\r\n}\r\n```\r\n3. Run it again but replace the `subAction` with `isolateHost`. Verify\r\nthat you get an unauthorized error.\r\n\r\n**Rule API and Feature Configuration Updates**\r\n1. 1. Enable the EDR connectors privilege in the role you created above\r\nand log in as the user you created above.\r\n2. Go to Stack Management\r\n3. Try to create a rule, and verify that you don't see the SentinelOne\r\nconnector.\r\n4. Try to create a rule using the API and add your SentinelOne\r\nconnector, verify that the API throws an error.\r\n```\r\nPOST kbn:/api/alerting/rule\r\n{\r\n \"tags\": [],\r\n \"params\": {},\r\n \"schedule\": {\r\n \"interval\": \"1m\"\r\n },\r\n \"consumer\": \"alerts\",\r\n \"name\": \"Always firing rule\",\r\n \"rule_type_id\": \"example.always-firing\",\r\n \"actions\": [\r\n {\r\n \"group\": \"small\",\r\n \"id\": \"$CONNECTOR_ID\",\r\n \"params\": {\r\n \"subAction\": \"isolateAgent\",\r\n \"subActionParams\": {}\r\n },\r\n \"frequency\": {\r\n \"notify_when\": \"onActionGroupChange\",\r\n \"throttle\": null,\r\n \"summary\": false\r\n }\r\n }\r\n ],\r\n \"alert_delay\": {\r\n \"active\": 1\r\n }\r\n}\r\n```\r\n5. You can test the same behaviors when trying to add a SentinelOne\r\nconnector to existing rules.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <[email protected]>","sha":"23a5c6d2db1cd8d501e94c1af872d4ce7792e9ee"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/203503","number":203503,"mergeCommit":{"message":"[ResponseOps] Granular Connector RBAC (#203503)\n\nPart of https://github.com/elastic/kibana/issues/180908\r\n\r\n## Summary\r\n\r\n**EDR Connector Subfeature Privilege**\r\nThis PR creates a new EDR connector sub-feature privilege under the read\r\nprivilege for connectors. The read privilege currently allows users to\r\nexecute connectors, and this new privilege will limit some of the\r\nconnectors that can be executed. When the EDR privilege is turned on,\r\nusers will be able to execute EDR connectors, and when it is off they\r\nwill not execute. This new privilege includes SentinelOne and\r\nCrowdstrike connectors.\r\n\r\nTo determine which connectors are considered EDR connectors, we\r\nleverage`getKibanaPrivileges` in the connector type definition. I\r\nremoved the restrictions to use this field only for system actions and\r\nrenamed `getSystemActionKibanaPrivileges` to\r\n`getActionKibanaPrivileges`. I also added a field, `subFeatureType `, to\r\nthe connector type definition to help disable testing/executing an\r\nconnectors that are restricted under a sub-feature.\r\n\r\n**EDR Connector Execution for Testing**\r\nThe execution of EDR connectors using the API is limited to a single\r\nsub-action for testing purposes. This ensures users can still\r\nconfigure/test EDR connectors. In a separate\r\n[PR](#204804), I added back the\r\nSentinelOne and Crowdstrike params UIs with options restricted to one\r\nsub-action.\r\n\r\n**Rule API and Feature Configuration Updates**\r\nValidation has been added to the rule APIs to enforce restrictions on\r\nadding EDR connectors. The connector feature configuration has been\r\nupdated to include a new feature ID, EdrForSecurityFeature, which\r\nensures that EDR connectors are hidden on the rule form.\r\nNote: I saw that EDR connectors are also temporarily restricted in the\r\nSecurity Solution UI. To streamline this, I removed the\r\n`isBidirectionalConnectorType` check in `action_type_registry.ts`.\r\nInstead, I removed `SecurityConnectorFeatureId` from the\r\n`supportedFeatureIds` of the SentinelOne connector type definition.\r\n\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\n- [ ] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n\r\n## To test\r\n\r\n**EDR Connector Subfeature Privilege**\r\n1. Create a new role and disable EDR connectors under the Actions and\r\nConnectors privilege\r\n2. Create a new user and assign that role to user\r\n3. Create a Sentinel One connector (It doesn't need to work, you can use\r\nfake values for the url and token)\r\n4. Login as the new user and run the following in Dev Tools to verify\r\nthat you aren't authorized execute the Sentinel One connector\r\n```\r\nPOST kbn:/api/actions/connector/$CONNECTOR_ID/_execute\r\n{\r\n \"params\": {\r\n \"subAction\": \"getAgents\",\r\n \"subActionParams\": {}\r\n }\r\n}\r\n```\r\n7. Update the role to enable EDR connectors and repeat the steps to\r\nverify that you are authorized to run the connector. (It will fail but\r\nverify it's not Unauthorized)\r\n\r\n**EDR Connector Execution for Testing**\r\n1. Enable the EDR connectors privilege in the role you created above and\r\nlog in as the user you created above.\r\n2. Run the following in Dev Tools to verify that you are authorized\r\nexecute the Sentinel One connector using only the `getAgents`\r\nsub-action. (It will fail but verify it's not `Unauthorized`)\r\n```\r\nPOST kbn:/api/actions/connector/$CONNECTOR_ID/_execute\r\n{\r\n \"params\": {\r\n \"subAction\": \"getAgents\",\r\n \"subActionParams\": {}\r\n }\r\n}\r\n```\r\n3. Run it again but replace the `subAction` with `isolateHost`. Verify\r\nthat you get an unauthorized error.\r\n\r\n**Rule API and Feature Configuration Updates**\r\n1. 1. Enable the EDR connectors privilege in the role you created above\r\nand log in as the user you created above.\r\n2. Go to Stack Management\r\n3. Try to create a rule, and verify that you don't see the SentinelOne\r\nconnector.\r\n4. Try to create a rule using the API and add your SentinelOne\r\nconnector, verify that the API throws an error.\r\n```\r\nPOST kbn:/api/alerting/rule\r\n{\r\n \"tags\": [],\r\n \"params\": {},\r\n \"schedule\": {\r\n \"interval\": \"1m\"\r\n },\r\n \"consumer\": \"alerts\",\r\n \"name\": \"Always firing rule\",\r\n \"rule_type_id\": \"example.always-firing\",\r\n \"actions\": [\r\n {\r\n \"group\": \"small\",\r\n \"id\": \"$CONNECTOR_ID\",\r\n \"params\": {\r\n \"subAction\": \"isolateAgent\",\r\n \"subActionParams\": {}\r\n },\r\n \"frequency\": {\r\n \"notify_when\": \"onActionGroupChange\",\r\n \"throttle\": null,\r\n \"summary\": false\r\n }\r\n }\r\n ],\r\n \"alert_delay\": {\r\n \"active\": 1\r\n }\r\n}\r\n```\r\n5. You can test the same behaviors when trying to add a SentinelOne\r\nconnector to existing rules.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <[email protected]>","sha":"23a5c6d2db1cd8d501e94c1af872d4ce7792e9ee"}},{"branch":"8.x","label":"v8.18.0","labelRegex":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT-->
kibanamachine
added a commit
that referenced
this pull request
Jan 7, 2025
…ting connectors in stack management (#204804) (#205648) # Backport This will backport the following commits from `main` to `8.x`: - [[ResponseOps] Granular Connector RBAC - adding back UIs for testing connectors in stack management (#204804)](#204804) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Alexi Doak","email":"[email protected]"},"sourceCommit":{"committedDate":"2025-01-06T19:27:54Z","message":"[ResponseOps] Granular Connector RBAC - adding back UIs for testing connectors in stack management (#204804)\n\nPart of https://github.com/elastic/kibana/issues/180908\r\n\r\n## Summary\r\n\r\nAs part of the changes for EDR Connector Execution for Testing, this PRs\r\nupdates the SentinelOne and Crowdstrike params UIs to limit to a single\r\nsub-action.\r\n\r\nSentinelOne:\r\n<img width=\"861\" alt=\"Screenshot 2024-12-18 at 11 16 49 AM\"\r\nsrc=\"https://github.com/user-attachments/assets/1a839d21-7ba7-4c4e-b3e9-8772725fad63\"\r\n/>\r\n\r\nCrowdstrike:\r\n<img width=\"855\" alt=\"Screenshot 2024-12-18 at 11 17 01 AM\"\r\nsrc=\"https://github.com/user-attachments/assets/b6c17964-8c49-4b5a-b1c7-bb4c6bb89621\"\r\n/>\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\n- [ ] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n### To test\r\n\r\n1. In Stack Management create SentinelOne and Crowdstrike connectors\r\n(They don't need to work, you can use fake values for the url and token)\r\n2. Test the new connectors. Verify that you only see one action type and\r\nthat it can't be changed and that the params are correctly sent in the\r\nrequest.","sha":"99f5e32fafe603d36ffd1b2f7556358a2855f2b6","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.18.0"],"title":"[ResponseOps] Granular Connector RBAC - adding back UIs for testing connectors in stack management","number":204804,"url":"https://github.com/elastic/kibana/pull/204804","mergeCommit":{"message":"[ResponseOps] Granular Connector RBAC - adding back UIs for testing connectors in stack management (#204804)\n\nPart of https://github.com/elastic/kibana/issues/180908\r\n\r\n## Summary\r\n\r\nAs part of the changes for EDR Connector Execution for Testing, this PRs\r\nupdates the SentinelOne and Crowdstrike params UIs to limit to a single\r\nsub-action.\r\n\r\nSentinelOne:\r\n<img width=\"861\" alt=\"Screenshot 2024-12-18 at 11 16 49 AM\"\r\nsrc=\"https://github.com/user-attachments/assets/1a839d21-7ba7-4c4e-b3e9-8772725fad63\"\r\n/>\r\n\r\nCrowdstrike:\r\n<img width=\"855\" alt=\"Screenshot 2024-12-18 at 11 17 01 AM\"\r\nsrc=\"https://github.com/user-attachments/assets/b6c17964-8c49-4b5a-b1c7-bb4c6bb89621\"\r\n/>\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\n- [ ] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n### To test\r\n\r\n1. In Stack Management create SentinelOne and Crowdstrike connectors\r\n(They don't need to work, you can use fake values for the url and token)\r\n2. Test the new connectors. Verify that you only see one action type and\r\nthat it can't be changed and that the params are correctly sent in the\r\nrequest.","sha":"99f5e32fafe603d36ffd1b2f7556358a2855f2b6"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/204804","number":204804,"mergeCommit":{"message":"[ResponseOps] Granular Connector RBAC - adding back UIs for testing connectors in stack management (#204804)\n\nPart of https://github.com/elastic/kibana/issues/180908\r\n\r\n## Summary\r\n\r\nAs part of the changes for EDR Connector Execution for Testing, this PRs\r\nupdates the SentinelOne and Crowdstrike params UIs to limit to a single\r\nsub-action.\r\n\r\nSentinelOne:\r\n<img width=\"861\" alt=\"Screenshot 2024-12-18 at 11 16 49 AM\"\r\nsrc=\"https://github.com/user-attachments/assets/1a839d21-7ba7-4c4e-b3e9-8772725fad63\"\r\n/>\r\n\r\nCrowdstrike:\r\n<img width=\"855\" alt=\"Screenshot 2024-12-18 at 11 17 01 AM\"\r\nsrc=\"https://github.com/user-attachments/assets/b6c17964-8c49-4b5a-b1c7-bb4c6bb89621\"\r\n/>\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\n- [ ] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n### To test\r\n\r\n1. In Stack Management create SentinelOne and Crowdstrike connectors\r\n(They don't need to work, you can use fake values for the url and token)\r\n2. Test the new connectors. Verify that you only see one action type and\r\nthat it can't be changed and that the params are correctly sent in the\r\nrequest.","sha":"99f5e32fafe603d36ffd1b2f7556358a2855f2b6"}},{"branch":"8.x","label":"v8.18.0","branchLabelMappingKey":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Alexi Doak <[email protected]>
viduni94
pushed a commit
to viduni94/kibana
that referenced
this pull request
Jan 23, 2025
Part of elastic#180908 ## Summary **EDR Connector Subfeature Privilege** This PR creates a new EDR connector sub-feature privilege under the read privilege for connectors. The read privilege currently allows users to execute connectors, and this new privilege will limit some of the connectors that can be executed. When the EDR privilege is turned on, users will be able to execute EDR connectors, and when it is off they will not execute. This new privilege includes SentinelOne and Crowdstrike connectors. To determine which connectors are considered EDR connectors, we leverage`getKibanaPrivileges` in the connector type definition. I removed the restrictions to use this field only for system actions and renamed `getSystemActionKibanaPrivileges` to `getActionKibanaPrivileges`. I also added a field, `subFeatureType `, to the connector type definition to help disable testing/executing an connectors that are restricted under a sub-feature. **EDR Connector Execution for Testing** The execution of EDR connectors using the API is limited to a single sub-action for testing purposes. This ensures users can still configure/test EDR connectors. In a separate [PR](elastic#204804), I added back the SentinelOne and Crowdstrike params UIs with options restricted to one sub-action. **Rule API and Feature Configuration Updates** Validation has been added to the rule APIs to enforce restrictions on adding EDR connectors. The connector feature configuration has been updated to include a new feature ID, EdrForSecurityFeature, which ensures that EDR connectors are hidden on the rule form. Note: I saw that EDR connectors are also temporarily restricted in the Security Solution UI. To streamline this, I removed the `isBidirectionalConnectorType` check in `action_type_registry.ts`. Instead, I removed `SecurityConnectorFeatureId` from the `supportedFeatureIds` of the SentinelOne connector type definition. ### Checklist Check the PR satisfies following conditions. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ## To test **EDR Connector Subfeature Privilege** 1. Create a new role and disable EDR connectors under the Actions and Connectors privilege 2. Create a new user and assign that role to user 3. Create a Sentinel One connector (It doesn't need to work, you can use fake values for the url and token) 4. Login as the new user and run the following in Dev Tools to verify that you aren't authorized execute the Sentinel One connector ``` POST kbn:/api/actions/connector/$CONNECTOR_ID/_execute { "params": { "subAction": "getAgents", "subActionParams": {} } } ``` 7. Update the role to enable EDR connectors and repeat the steps to verify that you are authorized to run the connector. (It will fail but verify it's not Unauthorized) **EDR Connector Execution for Testing** 1. Enable the EDR connectors privilege in the role you created above and log in as the user you created above. 2. Run the following in Dev Tools to verify that you are authorized execute the Sentinel One connector using only the `getAgents` sub-action. (It will fail but verify it's not `Unauthorized`) ``` POST kbn:/api/actions/connector/$CONNECTOR_ID/_execute { "params": { "subAction": "getAgents", "subActionParams": {} } } ``` 3. Run it again but replace the `subAction` with `isolateHost`. Verify that you get an unauthorized error. **Rule API and Feature Configuration Updates** 1. 1. Enable the EDR connectors privilege in the role you created above and log in as the user you created above. 2. Go to Stack Management 3. Try to create a rule, and verify that you don't see the SentinelOne connector. 4. Try to create a rule using the API and add your SentinelOne connector, verify that the API throws an error. ``` POST kbn:/api/alerting/rule { "tags": [], "params": {}, "schedule": { "interval": "1m" }, "consumer": "alerts", "name": "Always firing rule", "rule_type_id": "example.always-firing", "actions": [ { "group": "small", "id": "$CONNECTOR_ID", "params": { "subAction": "isolateAgent", "subActionParams": {} }, "frequency": { "notify_when": "onActionGroupChange", "throttle": null, "summary": false } } ], "alert_delay": { "active": 1 } } ``` 5. You can test the same behaviors when trying to add a SentinelOne connector to existing rules. --------- Co-authored-by: kibanamachine <[email protected]>
viduni94
pushed a commit
to viduni94/kibana
that referenced
this pull request
Jan 23, 2025
…onnectors in stack management (elastic#204804) Part of elastic#180908 ## Summary As part of the changes for EDR Connector Execution for Testing, this PRs updates the SentinelOne and Crowdstrike params UIs to limit to a single sub-action. SentinelOne: <img width="861" alt="Screenshot 2024-12-18 at 11 16 49 AM" src="https://github.com/user-attachments/assets/1a839d21-7ba7-4c4e-b3e9-8772725fad63" /> Crowdstrike: <img width="855" alt="Screenshot 2024-12-18 at 11 17 01 AM" src="https://github.com/user-attachments/assets/b6c17964-8c49-4b5a-b1c7-bb4c6bb89621" /> ### Checklist Check the PR satisfies following conditions. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### To test 1. In Stack Management create SentinelOne and Crowdstrike connectors (They don't need to work, you can use fake values for the url and token) 2. Test the new connectors. Verify that you only see one action type and that it can't be changed and that the params are correctly sent in the request.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Part of #180908
Summary
As part of the changes for EDR Connector Execution for Testing, this PRs updates the SentinelOne and Crowdstrike params UIs to limit to a single sub-action.
SentinelOne:
Crowdstrike:
Checklist
Check the PR satisfies following conditions.
To test