[POC] Granular Connector RBAC

[doakalexi]

Towards #194618

Summary

This PoC creates a new EDR connector subfeature 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.
To determine which connectors are considered EDR connectors, this PoC leverages 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, isEdrActionType, to the connector type definition to help disable testing/executing an EDR connector in the ui.

Below are some other changes we made after initial feedback for the PoC.

1. EDR Connector Execution for Testing
   The execution of EDR connectors in Stack Management is limited to a single sub-action for testing purposes. This ensures users can still configure/test EDR connectors. For the PoC, the SentinelOne params UI has been reintroduced with options restricted to one sub-action. In the final implementation, the UIs for all EDR connectors should be restored.

2. Rule API and Feature Configuration Updates

• Added validation to the rule APIs to enforce restrictions on adding EDR connectors.
• Updated the connector feature configuration to include a new feature ID, EdrForSecurityFeature, which hides EDR connectors on the rule form.
• 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.

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 401 Unauthorized)

---

1. Create a new user/use another other than the elastic user that has super privileges.
2. Create a Sentinel One connector (It doesn't need to work, you can use fake values for the url and token)
3. Login as the new user

EDR Connector Execution for Testing

1. Test the new connector you made, verify that in the UI you only can select the getAgents sub-action
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. Go to Stack Management
2. Try to create a rule, and verify that you don't see the SentinelOne connector.
3. 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
  }
}

4. You can test the same behaviors when trying to add a SentinelOne connector to existing rules.

[elasticmachine]

🤖 Jobs for this PR can be triggered through checkboxes. 🚧

ℹ️ To trigger the CI, please tick the checkbox below 👇

• Click to trigger kibana-pull-request for this PR!
• Click to trigger kibana-deploy-project-from-pr for this PR!

[paul-tavares]

Checked this PR out and ran through the changes implemented as well as some manual tests of interactions with SentinelOne. I left some screen captures below.

The implemented sub-privilege does seem to restrict execution of the connector's sub-actions when the sub-privilege is not defined in the role. Still unclear to me if this solution is acceptable by product. Will post back to the collaboration channel.

---

Tested with a new role that included the following:

This setup caused a failure (expected) when attempting to send a response action to SEntinelOne via Security's response console:

[paul-tavares]

Hi @doakalexi ,
Checked out the PR and the latest POC and it looks great. Below are some of the quick tests I ran through - all of them look good ✅ :

---

✅ If user does not have the new sub-privilage, they can't execute the test or connector actions via API

I also noticed that the new Sub-Privilege can be set for either all or read which is good and gives clients even more control

---

✅ Kibana Stack Connectors API prevents execution of connector sub-actions

---

✅ Response Actions from the security app can be executed if user has the EDR sub-privilege

I validate that a user can send response actions to SentinelOne and those actions complete as expected... this validate not only that the user can execute the connector's sub-actions that are not accessible via the Stack Connector's Kibana API, but also that the background task - which uses an un-privileged Sub-Actions client - can utilize the connector.

---

✅ User is provided an error in the Security console if they do not have the EDR sub-privilege

---

✅ The connector is not displayed or available for conjuration/use on SIEM Alert Rules