[Cases] RBAC

[jonathan-buttner]

Summary

This PR implements RBAC within the Cases plugin. Since the Security Solution app was already using Cases we also modified parts of that app so that it could continue using Cases correctly. The approach we took is similar to the alerting team's implementation of adding a new field on each of the saved objects within Cases to indicate which plugin is responsible for that entity. We call this field the owner.

RCF: #94054

Owner Field

APIs that create/update an entity require that the owner field be passed in the body of the request. APIs that search for entities typically require that the owner be passed as a query parameter. APIs that specify an ID of an entity directly generally don't need to specify the owner field.

For APIs that create/update an entity, the RBAC implementation checks to see if the user making the request has the correct privileges for performing that action (a create/update) for the specified owner. This check is done through the Security plugin's API.

For APIs that search for entities, the RBAC implementation creates a filter for the saved objects query that limits the search to only owners that the user has access to. We also check that the objects returned by the saved objects API have the limited owner scope. If we find one that the user does not have permissions for, we throw a 403 error. The owner field that is passed in as a query parameter can be used to further limit the results. If a user attempts to pass an owner that they do not have access to, the owner is ignored.

For APIs that retrieve/delete entities directly using their ID, the RBAC implementation requests the object first, and then checks to see if the user making the request has access to that operation and owner. If the user does, the operation continues, otherwise we throw a 403.

Limitations

• The RBAC implementation does not currently support limiting users from creating certain entities but not others. If a user is granted all access they can create all types of entities (cases, comments, etc)
  • If we have requirements in the future to support this, we should be able to do it without a breaking change
• RBAC was not implemented in the case as a connector feature because the feature is currently disabled and we a KibanaRequest and SavedObjectsClient exposed by the actions framework
  • This includes the sub case routes, we have tests to ensure that none of the sub case routes are registered and that the client throws an error if it is called through the exposed client contract

Testing

• We wrote integration tests for three main scenarios
  • When the security and spaces plugin are enabled (with license sent to basic and trial)
  • When the security plugin is enabled but spaces is disabled (trial license only)
  • When the spaces plugin is enabled but the security plugin is disabled (trial license only)

The security and spaces scenario has most of the coverage in it as it includes all the previous integration tests that existed in cases and we added tests for the RBAC implementation for each HTTP route that we added it to.

The security only scenario includes tests for the RBAC implementation to ensure that it works even when the only space available is the default one since the spaces plugin is disabled.

The spaces only scenario includes tests to make sure that basic interactions with the HTTP APIs work correctly when not leveraging RBAC.

Notable Changes

• Cases Client
  • Each HTTP route is now supported through the Cases client to allow other plugin's server code to interact with Cases without needing to go through HTTP routes
• HTTP Routes
  • To avoid duplication of functionality the bulk of the routes implementation was pushed into the cases client
  • Many of routes that the UI interacts with now require the owner to be passed to the backend
  • Interacting with the Configurations API now requires an ID because multiple configurations can exist (one per owner)

Example Requests

Create case

curl --location --request POST 'http://localhost:5601/api/cases' \
--header 'kbn-xsrf: true' \
--header 'Authorization: Basic <token>' \
--header 'Content-Type: application/json' \
--data-raw '{
    "title": "RBAC",
    "tags": [
        "rbac"
    ],
    "connector": {
        "id": "none",
        "name": "none",
        "type": ".none",
        "fields": null
    },
    "description": "Testing RBAC",
    "settings": {
        "syncAlerts": true
    },
    "type": "individual",
    "owner": "securitySolution"
}'

Find cases

curl --location --request GET 'http://localhost:5601/api/cases/_find?status=open&page=1&perPage=5&sortField=createdAt&sortOrder=desc&owner=securitySolution&owner=observability' \
--header 'kbn-xsrf: true' \
--header 'Authorization: Basic <token>'

Release Notes

• The new owner field is now mandatory for the following routes:

  • Create cases: POST /api/cases
  • Add comment: POST /api/cases/<case_id>/comments
  • Create case configuration: POST /api/cases/configure

• The new owner field can be passed as a query parameter to the following routes:

  • Find cases: GET /api/cases/_find
  • Get tags: GET /api/cases/tags
  • Get reporters: GET /api/cases/reporters
  • Find cases by alert id: GET /api/cases/alerts/<alert_id>

• Most of the HTTP responses contain the owner attribute.

• The get configuration API route returns an array of configuration instead of a single object configuration.

• Update configuration API route changed from PATCH /api/cases/configure to PATCH /api/cases/configure/<configuration_id>

[stephmilovic]

GET => DELETE in these logs

[cnasikas]

Fixed in #101465

[stephmilovic]

Maybe something for your follow up PR but I know there are a lot of places with caseId (lowercase d). Perhaps we should be consistent with how we camelcase ID

[stephmilovic]

OMG I finally reached the end!

That's one to remember. Incredible work and congrats to @jonathan-buttner and @cnasikas. This was a HUGE undertaking and I'm super impressed with what you two were able to accomplish. I can't wait to get this merged! LTFF 🚀 🎸 🥁 🎺 🏁 🐎 🏎️

[jonathan-buttner]

@elasticmachine merge upstream

[cnasikas]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 56e0f0d
• Storybooks Preview
• Documentation Changes

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
cases	252	255	+3

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
cases	374	382	+8
features	94	97	+3
total			+11

Async chunks

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

id	before	after	diff
cases	494.3KB	502.1KB	+7.8KB
securitySolution	6.9MB	6.9MB	+97.0B
total			+7.9KB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
cases	16	13	-3

Page load bundle

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

id	before	after	diff
cases	127.4KB	133.5KB	+6.1KB
features	6.6KB	6.6KB	+37.0B
total			+6.1KB

Saved Objects .kibana field count

Every field in each saved object type adds overhead to Elasticsearch. Kibana needs to keep the total field count below Elasticsearch's default limit of 1000 fields. Only specify field mappings for the fields you wish to search on or query. See https://www.elastic.co/guide/en/kibana/master/development-plugin-saved-objects.html#_mappings

id	before	after	diff
cases	41	42	+1
cases-comments	24	25	+1
cases-configure	19	20	+1
cases-connector-mappings	5	6	+1
cases-user-actions	10	11	+1
total			+5

Unknown metric groups

API count

id	before	after	diff
cases	387	407	+20
features	206	215	+9
total			+29

History

• 💚 Build #129276 succeeded 5bd080b
• 💚 Build #128983 succeeded 739fd6f
• 💚 Build #128940 succeeded 7ef02f4
• 💔 Build #128919 failed d59dbad
• 💚 Build #128756 succeeded 373cd68

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @cnasikas @jonathan-buttner

[legrego]

LGTM! Fantastic job on this one, folks 🏅 . Thanks for all of your patience and revisions too