Open legrego opened 3 years ago
Pinging @elastic/kibana-security (Team:Security)
I updated the description a bit and added a Potential future usages of custom authorization
section.
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.
@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:
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.
(not sure if this is directly related to this issue, but) @legrego following up on https://github.com/elastic/kibana/pull/95058#discussion_r634176198, one other improvement would be to allow plugins to register feature capabilities without being forced to impact the features
plugin's codebase.
(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
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.
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.
all
/read
: https://github.com/elastic/kibana/issues/105512As 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:
Potential future usages of custom authorization: