Evolving Kibana's authorization model

[legrego]

Kibana authorization model was built in a much simpler time. Our needs are growing more sophisticated by the day, and our authorization model has not kept pace with the needs of our solutions.

• Authorize saved objects by more than just their type (Saved-objects authorization more granular than type #47503)
• Allow features to be renamed, spliced, and diced (Security migrations #68814)
• Allow features to span both Kibana and Elasticsearch privileges ("Composite features" Support for composite features #96598)
• Allow features to declare privileges other than all/read: "Actions & Connectors" users are surprised by the fact that users with read-only permissions can test connectors and execute actions #105512
• Separate the concept of feature and privilege. (Rethink user privileges for the observability solution #117339)
• Refactor Capabilities Switcher (Refactor Security Plugin Capabilities Switcher #155197)

As a result of these limitations, solution teams have had to implement their own RBAC using our security primitives, which weren't originally designed for such broad consumption. We need to evolve our security model so that solution teams don't need to write their own authorization logic.

Known usages of custom authorization:

• Connectors
• Rules
• Cases

Potential future usages of custom authorization:

• Alerts
• Notifications
• Scheduled reports
• Background searches?

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[mikecote]

I updated the description a bit and added a Potential future usages of custom authorization section.

[legrego]

Thanks, @mikecote -- are you aware of the requirements for the potential future usages? That would be really helpful to make sure we're building something that'll actually meet our needs of tomorrow.

[mikecote]

@legrego the main pattern I see for the potential future usages is to have a single saved object type serve multiple features and limit access based on the inherited feature on a per-document basis. I'll put some examples below, but @ppisljar and @Bamieh keep me honest on my speculation:

• Notifications (speculation): Different features create notifications, and access to those notifications should reflect the user's feature access.
• Scheduled reports (speculation): Different features create scheduled reports, and access to those reports should reflect the user's feature access.
• Background searches (speculation): If they are visible outside the user searching, I'm guessing different features would create them, and access to those background searches should reflect the user's feature access.

[ppisljar]

at the moment we don't plan to make background searches accessible to other users (apart from the one creating it) but i agree that would make a lot of sense with reporting.

[pgayvallet]

(not sure if this is directly related to this issue, but) @legrego following up on #95058 (comment), one other improvement would be to allow plugins to register feature capabilities without being forced to impact the features plugin's codebase.

[legrego]

(not sure if this is directly related to this issue, but) @legrego following up on #95058 (comment), one other improvement would be to allow plugins to register feature capabilities without being forced to impact the features plugin's codebase.

@pgayvallet I think the changes necessary to evolve Kibana's authorization model will require a more robust features implementation, so I expect that we will end up addressing both at the same time

[semd]

At the request of @azasypkin, I'll explain the limitation we ran into with the superuser role in Security Solution for serverless:

We set up the Kibana features configuration to register dynamically based on the type of product being used (like Essentials or Complete).

So, some features and action privileges don't get registered in Kibana when using the "Essentials tier," for example. Consequently, we expected the Elasticsearch hasPrivileges API to return false for privileges or actions that don't exist. Since it behaved as expected with regular roles, we streamlined roles and product-level checks based on this assumption.

However, we later found out that hasPrivileges didn't behave the same way for the superuser (or any *) role. This API consistently returned true for the superuser, regardless of whether the action or privilege existed or not.

This was breaking our checks for product features when accessed by these * roles in serverless. So, we initiated a discussion with the security team to address the issue. They explained that this behavior for the superuser role was deliberately implemented to solve another specific problem (though I can't recall which one), and it wasn't feasible to alter this behavior to be consistent with the rest of the roles.

In the end, we implemented a workaround on the Security Solution side by verifying if the privilege or action to check exists in the config object we registered as Kibana features, before calling the hasPrivilege API.