Granular Connector RBAC #180908

kobelb · 2024-04-16T12:00:39Z

Situation

At the moment, all access to connectors is controlled by the "Actions and Connectors" feature privilege. The following summarizes the access that is granted by "All"/"Read" access to the "Actions and Connectors" feature privilege:

Action	All	Read
Create connector	✅	❌
Edit connectors	✅	❌
View connectors	✅	✅
Execute connectors	✅	✅ (except SentinelOne)

This coarse privileges model has caused complications with EDR connectors, for example SentinelOne. These EDR connectors can perform very powerful operations, for example isolating a host, and treating them the same as all other connectors has raised concern with the Security Solution's - EDR Workflows team. Short-term, we decided to treat the SentinelOne connector differently than all other connectors, and users are required to have the "Actions and Connectors - All" feature privilege to execute any SentinelOne actions. However, this is not a good long-term solution because it's unintuitive (it's not obvious to users that SentinelOne behaves differently than all the other connectors), and it doesn't allow the user to explicitly choose whether or not the user should be authorized to execute actions for different connector types.

Proposed Solution

I originally proposed utilizing sub-feature privileges for each of the connector types to the EDR Workflows team, and adding a sub-feature privilege for each of the actions that can be invoked:

However, the EDR Workflows team raised some concerns regarding this approach being TOO granular, and would prefer something less granular where they could grant people access to all EDR connectors, not connector-by-connector and action-by-action. We should take this feedback, and feedback from other teams into consideration before finalizing a solution.

kobelb · 2024-04-16T12:00:53Z

/cc @shanisagiv1

elasticmachine · 2024-04-16T12:01:26Z

Pinging @elastic/response-ops (Team:ResponseOps)

@timestamp

…204114) Part of #180908 ## Summary This change is part of adding granular RBAC for SecuritySolution connectors. In this PR, I updated the action executor to log API key details when a connector is executed by a user authenticated via API key. The public name and id of the API key are now included in the event log. ### 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 verify 1. Create an API key 2. Create a connector that will successfully run, it doesn't have to be SentinelOne. 3. Run the following with the ID and correct params for your connector type. ``` curl -X POST "http://localhost:5601/api/actions/connector/$CONNECTOR_ID/_execute" -H 'Authorization: ApiKey $API_KEY' -H 'kbn-xsrf: true' -H 'Content-Type: application/json' -d' { "params": { "message": "hi" } }' ``` 4. Go to dev tools and run the following query to verify that the API key information is stored in the event log ``` GET /.kibana-event-log*/_search { "sort": [ { "@timestamp": { "order": "desc" } } ], "query": { "bool": { "filter": [ { "term": { "event.provider": { "value": "actions" } } } ] } } ```

@timestamp

…lastic#204114) Part of elastic#180908 ## Summary This change is part of adding granular RBAC for SecuritySolution connectors. In this PR, I updated the action executor to log API key details when a connector is executed by a user authenticated via API key. The public name and id of the API key are now included in the event log. ### 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 verify 1. Create an API key 2. Create a connector that will successfully run, it doesn't have to be SentinelOne. 3. Run the following with the ID and correct params for your connector type. ``` curl -X POST "http://localhost:5601/api/actions/connector/$CONNECTOR_ID/_execute" -H 'Authorization: ApiKey $API_KEY' -H 'kbn-xsrf: true' -H 'Content-Type: application/json' -d' { "params": { "message": "hi" } }' ``` 4. Go to dev tools and run the following query to verify that the API key information is stored in the event log ``` GET /.kibana-event-log*/_search { "sort": [ { "@timestamp": { "order": "desc" } } ], "query": { "bool": { "filter": [ { "term": { "event.provider": { "value": "actions" } } } ] } } ``` (cherry picked from commit 1ba2716)

@timestamp

…lastic#204114) Part of elastic#180908 ## Summary This change is part of adding granular RBAC for SecuritySolution connectors. In this PR, I updated the action executor to log API key details when a connector is executed by a user authenticated via API key. The public name and id of the API key are now included in the event log. ### 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 verify 1. Create an API key 2. Create a connector that will successfully run, it doesn't have to be SentinelOne. 3. Run the following with the ID and correct params for your connector type. ``` curl -X POST "http://localhost:5601/api/actions/connector/$CONNECTOR_ID/_execute" -H 'Authorization: ApiKey $API_KEY' -H 'kbn-xsrf: true' -H 'Content-Type: application/json' -d' { "params": { "message": "hi" } }' ``` 4. Go to dev tools and run the following query to verify that the API key information is stored in the event log ``` GET /.kibana-event-log*/_search { "sort": [ { "@timestamp": { "order": "desc" } } ], "query": { "bool": { "filter": [ { "term": { "event.provider": { "value": "actions" } } } ] } } ```

@timestamp

…lastic#204114) Part of elastic#180908 ## Summary This change is part of adding granular RBAC for SecuritySolution connectors. In this PR, I updated the action executor to log API key details when a connector is executed by a user authenticated via API key. The public name and id of the API key are now included in the event log. ### 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 verify 1. Create an API key 2. Create a connector that will successfully run, it doesn't have to be SentinelOne. 3. Run the following with the ID and correct params for your connector type. ``` curl -X POST "http://localhost:5601/api/actions/connector/$CONNECTOR_ID/_execute" -H 'Authorization: ApiKey $API_KEY' -H 'kbn-xsrf: true' -H 'Content-Type: application/json' -d' { "params": { "message": "hi" } }' ``` 4. Go to dev tools and run the following query to verify that the API key information is stored in the event log ``` GET /.kibana-event-log*/_search { "sort": [ { "@timestamp": { "order": "desc" } } ], "query": { "bool": { "filter": [ { "term": { "event.provider": { "value": "actions" } } } ] } } ```

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 <42973632+kibanamachine@users.noreply.github.com>

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 <42973632+kibanamachine@users.noreply.github.com> (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

…onnectors in stack management (#204804) 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: <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.

…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)

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 <42973632+kibanamachine@users.noreply.github.com>

…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.

@timestamp

…lastic#204114) Part of elastic#180908 ## Summary This change is part of adding granular RBAC for SecuritySolution connectors. In this PR, I updated the action executor to log API key details when a connector is executed by a user authenticated via API key. The public name and id of the API key are now included in the event log. ### 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 verify 1. Create an API key 2. Create a connector that will successfully run, it doesn't have to be SentinelOne. 3. Run the following with the ID and correct params for your connector type. ``` curl -X POST "http://localhost:5601/api/actions/connector/$CONNECTOR_ID/_execute" -H 'Authorization: ApiKey $API_KEY' -H 'kbn-xsrf: true' -H 'Content-Type: application/json' -d' { "params": { "message": "hi" } }' ``` 4. Go to dev tools and run the following query to verify that the API key information is stored in the event log ``` GET /.kibana-event-log*/_search { "sort": [ { "@timestamp": { "order": "desc" } } ], "query": { "bool": { "filter": [ { "term": { "event.provider": { "value": "actions" } } } ] } } ```

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 <42973632+kibanamachine@users.noreply.github.com>

…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.

kobelb added Feature:Actions/ConnectorTypes Issues related to specific Connector Types on the Actions Framework Feature:Actions/ConnectorsManagement Issues related to Connectors Management UX labels Apr 16, 2024

botelastic bot added the needs-team Issues missing a team label label Apr 16, 2024

kobelb added the Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) label Apr 16, 2024

botelastic bot removed the needs-team Issues missing a team label label Apr 16, 2024

kobelb added the needs-team Issues missing a team label label Apr 16, 2024

botelastic bot removed the needs-team Issues missing a team label label Apr 16, 2024

doakalexi mentioned this issue Oct 1, 2024

[Research] Granular Connector RBAC #194618

Closed

mikecote assigned doakalexi Oct 21, 2024

This was referenced Dec 13, 2024

[ResponseOps] Granular Connector RBAC - adding API key to event log #204114

Merged

[ResponseOps] Granular Connector RBAC #203503

Merged

[ResponseOps] Granular Connector RBAC - adding back UIs for testing connectors in stack management #204804

Merged

doakalexi closed this as completed Jan 6, 2025

lcawl mentioned this issue Jan 17, 2025

[DOCS] Granular connector RBAC #207136

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Granular Connector RBAC #180908

Granular Connector RBAC #180908

kobelb commented Apr 16, 2024

kobelb commented Apr 16, 2024

elasticmachine commented Apr 16, 2024

Granular Connector RBAC #180908

Granular Connector RBAC #180908

Comments

kobelb commented Apr 16, 2024

Situation

Proposed Solution

kobelb commented Apr 16, 2024

elasticmachine commented Apr 16, 2024