Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
# 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":"109488926+doakalexi@users.noreply.github.com"},"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 <42973632+kibanamachine@users.noreply.github.com>","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 <42973632+kibanamachine@users.noreply.github.com>","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 <42973632+kibanamachine@users.noreply.github.com>","sha":"23a5c6d2db1cd8d501e94c1af872d4ce7792e9ee"}},{"branch":"8.x","label":"v8.18.0","labelRegex":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT-->
- Loading branch information