[ResponseOps] Granular Connector RBAC

[doakalexi]

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 leveragegetKibanaPrivileges 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, 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 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.

[js-jankisalvi]

Verified below scenarios locally and they are working as expected 🎉

• disabled EDR connectors ✅
• enabled EDR connectors ✅
• Run it again but replace the subAction with isolateHost. ✅
• Try to create a rule, and verify that you don't see the SentinelOne connector. ✅
• Try to create a rule using the API and add your SentinelOne connector, verify that the API throws an error. ✅
• Test the same behaviors when trying to add a SentinelOne connector to existing rules. ✅

[pmuellr]

@cnasikas Thought you might want to take a look, since you seem to be the RBAC / subaction connectors expert. At least to see what changes are being made ...

[pmuellr]

LGTM. Left a comment about the text of an error message that feel like could be improved.

[pmuellr]

This makes it sound like there is a problem with the EDR connector, but actually the problem is that you can't use these connectors as alerting actions, correct? If so, perhaps the message should be something like "EDR connectors cannot be used as alerting actions" or similar ...

[doakalexi]

Thanks for catching updated in the commit, aa216e6

[doakalexi]

I also updated the naming from subFeatureType -> subFeature and edr -> endpointSecurity in this commit
cc @mikecote

[kdelemme]

code change LGTM

[e40pud]

Security GenAI changes LGTM

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 66103c8

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
@kbn/actions-types	14	17	+3
@kbn/alerts-ui-shared	286	287	+1
actions	315	325	+10
triggersActionsUi	568	570	+2
total			+16

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
triggersActionsUi	1.7MB	1.7MB	-287.0B
uptime	458.4KB	458.4KB	+27.0B
total			-260.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
actions	17.4KB	17.7KB	+331.0B
triggersActionsUi	126.9KB	127.0KB	+27.0B
total			+358.0B

Unknown metric groups

API count

id	before	after	diff
@kbn/actions-types	14	17	+3
@kbn/alerts-ui-shared	302	303	+1
actions	321	331	+10
triggersActionsUi	594	596	+2
total			+16

History

• 💔 Build #264387 failed 6855741
• 💔 Build #263674 failed be33125
• 💔 Build #263381 failed a0a14ac
• 💔 Build #263012 failed 7d000b3
• 💔 Build #262553 failed d12aa20

[kibanamachine]

Starting backport for target branches: 8.x

https://github.com/elastic/kibana/actions/runs/12638516032

[kibanamachine]

💔 All backports failed

Status	Branch	Result
❌	8.x	Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

node scripts/backport --pr 203503

Questions ?

Please refer to the Backport tool documentation

[doakalexi]

💚 All backports created successfully

Status	Branch	Result
✅	8.x

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

[pmuellr]

s/IEndpoint/Endpoint/

[doakalexi]

Thanks! Should have been fixed in this commit, 66103c8

[pmuellr]

yup, was looking at a stake copy ...