API Key Management

[kobelb]

When Elasticsearch introduces long-lived tokens, they're going to be a snapshot of the user's effective privileges at the time that the token was created. Relatedly, when a user is deleted their long-lived token won't be automatically invalidated.

We'd like to add a section to the user management screens in Kibana that will list the user's long-lived tokens and allow these to be invalidated, and potentially prompt the user if they'd like to invalidate the tokens when the user is deleted.

[elasticmachine]

Pinging @elastic/kibana-security

[legrego]

I think this is a great idea.

Expanding on this, I see two potential views (depending on user privileges):

1. Allow each user to see & invalidate their own tokens
2. Allow users with manage_security to see & invalidate tokens for other users

Somewhat unrelated, we expect to use long-lived tokens as a Kibana auth mechanism, right? I wonder if we will want/need a way to invalidate these tokens if roles end up changing. For example, if an admin wants to revoke manage_security from a specific user, but that user has a long-lived token already, the revocation wouldn't take effect until that token was destroyed. Will we have visibility into these tokens to see what the effective privileges are?

[legrego]

Elasticsearch merged support for long-lived tokens (called api keys) in elastic/elasticsearch#38291 supporting the following:

• Create API Key - PUT/POST /_security/api_key
• Get API key(s) - GET /_security/api_key
• Invalidate API Key(s) DELETE /_security/api_key

Retrieving API Keys requires us to specify at least one of:

1. realm
2. username
3. token id
4. token name

It'll be easy enough for us to create a UI showing tokens for the currently logged in user, or all tokens for the native realm. It might get tricky to show tokens for other realms, as we don't necessarily know which realms are configured in Elasticsearch.

An update on my question above:

Somewhat unrelated, we expect to use long-lived tokens as a Kibana auth mechanism, right? I wonder if we will want/need a way to invalidate these tokens if roles end up changing. For example, if an admin wants to revoke manage_security from a specific user, but that user has a long-lived token already, the revocation wouldn't take effect until that token was destroyed. Will we have visibility into these tokens to see what the effective privileges are?

When you create a token via this API, you are asked to specify a role definition which explains the privileges this token should be granted. You don't necessarily tie this to an existing role, but grant privileges "on the fly" when the token is created. So revoking access across all tokens for a specific user isn't something we'll support (for now), if I understand correctly.

The GET API also doesn't (currently) return details explaining which privileges are granted to the token, so our UI won't be able to either. We have the following fields:

1. Token Name (user provided via create api)
2. Token Id (system generated)
3. Username
4. Realm
5. Creation time (epoch)
6. Invalidated flag

[epixa]

If this UI is specific to the current user, we should make it accessible through the user dropdown (where change password is) instead of in the management app

[kobelb]

If this UI is specific to the current user, we should make it accessible through the user dropdown (where change password is) instead of in the management app

We're tracking that functionality here: #34820

[elasticmachine]

Pinging @elastic/es-ui

[cjcenizal]

@legrego Can we either close this issue or relabel it for the Security team?