Allow creation of API keys on behalf of other users

[peterschretlen]

The manage_own_api_key role allows creating a point-in-time snapshot of an authenticated user's permissions, that does not expire. This is ideal for Kibana alerting which runs scheduled background alert checks where permissions need to be enforced but the authenticated user isn't around.

However most users won't have the manage_own_api_key role. Generally this should be an explicitly granted privilege.

Would it be possible to allow a user (like the kibana system user) to create API keys on behalf of other users (similar to the token api )?

The user of a service like alerting would then require no special privileges. They would not need access to (or even awareness of) the API keys created on their behalf. The system user could be restricted to creating keys for users whose credentials they have ( like a user submitting a request to create an alert, for example ).

[elasticmachine]

Pinging @elastic/es-security (:Security/Authentication)

[bytebilly]

@peterschretlen I'm not sure I'm getting what you mean when you say "API keys created on their behalf". If they don't need to access and manage those keys, which is the difference if the keys are created by the kibana user or on behalf of another user?

What I think is important is the set of privileges, and those are not following the "original" user anyway.

Even if creating keys on behalf of another user, they would never get more privileges than the current user (the one performing the request), or it could gain those privileges too.

Could you please help to clarify? Thanks!

[peterschretlen]

I'm not sure I'm getting what you mean when you say "API keys created on their behalf". If they don't need to access and manage those keys, which is the difference if the keys are created by the kibana user or on behalf of another user?

The difference is the API key would be a privilege snapshot of the 'target' user, not a privilege snapshot of the user who is making the request to elasticsearch.

The idea is an internal kibana system user ( which has very limited privileges - it only has read/write access to the system indices it needs to operate) could take create an API key of the end-user logged into Kibana (who will have privileges to data they want to run background jobs on) when they request a background job to be created and run.

Even if creating keys on behalf of another user, they would never get more privileges than the current user (the one performing the request), or it could gain those privileges too.

The API key should represent the 'target' user permissions, so yes there's risk that the 'requesting' user captures that key and now has expanded privileges. That's one way to look at what the internal Kibana system user would be doing, but this action must be initiated by the target authenticated user, with the intent of creating a background task owned by that target user.

In general we want users to have API keys, but not require users to be able to create their own API keys.

cc @mikecote @tvernum

[bytebilly]

The API key should represent the 'target' user permissions, so yes there's risk that the 'requesting' user captures that key and now has expanded privileges.

The caller will always be able to create an API key on behalf of another user (let's say elastic), and access its value. Then the caller can use this API key to run any other call with the elastic privileges.
If the caller is not able to access this value, nobody else will and they key cannot be used.

That's one way to look at what the internal Kibana system user would be doing, but this action must be initiated by the target authenticated user, with the intent of creating a background task owned by that target user.

From an Elasticsearch point of view, it's not important how the action starts in Kibana, but who authenticates to make the request. In this case, it would be an "unprivileged" user that will receive a key that can be used for potentially "privileged" requests.

Maybe I'm missing something, so please be patient if I don't see the point. I understand the need, but I'm not sure this is the safe way to address it.

What do you think?

In general we want users to have API keys, but not require users to be able to create their own API keys.

Having a key means just knowing the id/value, and there is no real connection with the user once created (except for the ownership relationship that is used by the manage_own_api_key

[peterschretlen]

The hope is for something similar to the token API. Since the logged-in user is initiating the request (and assume the kibana system has the credentials in some form), then I don't see it as much different than the token API:

POST /_security/oauth2/token
{
  "grant_type" : "password",
  "username" : "test_admin",
  "password" : "x-pack-test-password"
}

We'd use token API (without needing kibana system at all) except for the fact that tokens have an expiry, and these background alerting jobs may run indefinitely.

[bytebilly]

Thanks @peterschretlen, now I can see the full picture and how it is supposed to work. I was missing using the current target credentials in the request.

[mikecote]

@tvernum from our previous conversation a few weeks ago, you were waiting to know what time frame we would be able to test this feature and ensure what is built is suitable for our needs. I have an answer for this now which would be late January (7.7 scope). This will give us enough time to also implement the feature on our side within the same release. Let me know what you think and we will reserve time for testing / validating.

[albertzaharovits]

I would like to float an idea which is a bit on the wilder side:

Instead of having the kibana_system have the privilege to generate API Keys for other users (given their credentials, which could be a short lived token in the SAML/OIDC realm case), could the user be able to generate API Keys for himself without requiring any privilege? In essence, could we be deprecating the manage_own_api_key privilege and grant the permission to everyone?

[tvernum]

could we be deprecating the manage_own_api_key privilege and grant the permission to everyone?

No, we absolutely don't want to do that.

If everyone can create API Keys then they become a backdoor for avoiding the authentication controls that the admin has put in place (MFA/PKI). We have intentionally made them an opt-in feature per user.

As an example, if you configure your cluster to require SAML in order to satisfy certain security policies (MFA, password policies, account locking, etc) but your SAML users are allowed to create API Keys, then they can simply by-pass all of those protections.
The only option to solve that is to turn off API-keys across the board, but then you can't use alerting.

The option proposed here is safe because the user never gets access to the API key secret. Alerting actually "owns" the API key and protects it so that the user doesn't have direct access to the cluster, but Alerting can run tasks on their behalf.

[peterschretlen]

Perhaps the scope of this needs to be both create and invalidate ?

When we update an alert, we also update the API key on the alert to reflect any changes in the user's privileges. To prevent a lot of 'dangling' API keys we'd also like to invalidate the old key, or at least prevent it from cluttering the API key UI view in Kibana.

See elastic/kibana#54525 for an example of this, where the alerts for SIEM detection engine in 7.6 can be updated, but they leave behind 'dangling' keys when the user has only the manage_own_api_key privilege.

[peterschretlen]

@tvernum from our previous conversation a few weeks ago, you were waiting to know what time frame we would be able to test this feature and ensure what is built is suitable for our needs. I have an answer for this now which would be late January (7.7 scope). This will give us enough time to also implement the feature on our side within the same release. Let me know what you think and we will reserve time for testing / validating.

@tvernum @bytebilly since we're about to start 7.7, I wanted to make sure this is still part of your 7.7 plans? We still expect to be able to test this by late January.