-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add API Keys app to Management > Security. #45740
Conversation
Pinging @elastic/kibana-security |
💔 Build Failed |
@cjcenizal I like it! This allows users to manage their own keys, that is great, but if I get it correctly it doesn't allow "admins" to manage the entire list of keys (e.g., application keys for APM). I'm not sure if we need to expose the What do you think? |
I haven't pulled this PR down to look yet, but if this is the case, maybe API key management would make more sense as part of the user profile page, rather than under the security management interface? |
It makes sense, as this is normally the place where you manage your own API keys in other software (GitHub, GitLab, etc). I'm still wondering how the "admin" management works. If we want to reuse the same panel for both "admin" and "own" flows, probably the user profile doesn't fit very well since it's not the place I'd go, as an "admin", to manage the keys for the entire instance. Having two places where the same component is reused makes sense, anyway, from a logical point of view. |
I agree, the management interface to administer other user's keys wouldn't make sense in the user profile. I would expect that to live in the |
Yes, this is correct. It seems like the current API doesn't expose an easy way of retrieving all existing keys. Do you know who I could ping about that / would you mind following up on that for me?
Works for me. I will move this detail into a separate detail panel and out of the table.
I think this makes a lot of sense. I'll make this change, thanks for the suggestion! |
I'll bring this question to the team, and we'll take the opportunity to talk about the future of API keys API (inception intended 🙂). |
Playing around with the get API keys API, looks like there’s not currently a way to list all API keys. If you know a specific username and you’re an admin, you can list their keys. Wildcards don’t work for username, and if you specify only a realm_name, you get nothing back. The alerting project was hoping for a screen where an admin could go in and disable all API keys for a given user, say they’ve left the company, or have had their access revoked or changed. CJ had a good idea where you could select another user and then be shown all their keys. Verified that I can see other user's keys with cluster "all" privilege. |
@cjcenizal based on discussions we had, we should carefully consider the use case that the feature is trying to address (limited scope service accounts), and defer the personal access token flow when/if we'll move in that direction. I feel the UX for this is essential to guarantee that the current API keys are used properly and not misunderstood in scope. Discussion about getting more information in the response is in elastic/elasticsearch#46887. |
bf389df
to
7b3049b
Compare
💔 Build Failed |
7b3049b
to
c0673d2
Compare
💔 Build Failed
|
c0673d2
to
82c1c06
Compare
💔 Build Failed
|
318b75a
to
fe9a04a
Compare
…y keys past their expiration dates.
Using the Shield plugin methods instead
- Use '/internal/security' route. - Move to internal v1 directory. - Use Joi validation.
@kobelb @gchaps @alisonelizabeth Thanks for your feedback! I've incorporated the changes I think are appropriate for this stage. Brandon, could you please re-review and approve if you're OK with merging this? |
💔 Build Failed |
💔 Build Failed |
Retest |
💔 Build Failed |
Last nit-picks, I promise
💔 Build Failed |
💚 Build Succeeded |
💚 Build Succeeded |
* Add API Keys app to Management > Security. - For admins, list all API Keys created by the user: Name, Date Created, Expiration Date, Status, User, and Realm. - For non-admins, list own API keys: Name, Date Created, Expiration Date, and Status. - Surface admin status above table. - Ability to search by Name and Revoke (invalidate) API keys, and filter by User and Realm. - Surface feedback when API keys are disabled on Elasticsearch or when user lacks required permissions. * Add `SectionLoading` component to `es_ui_shared` plugin.
Release note
The API Keys app allows users to view and invalidate their own API keys and administrators to view and invalidate all users' API keys.
Details
Loading state
API keys not enabled state
Loading error state
Not allowed state
If the user doesn't have
manage_security
,manage_api_key
, and/ormanage_own_api_key
permissions, they'll be disallowed from using this app.Admin view
If the user has
manage_security
ormanage_api_key
privileges, they have the ability to see and invalidate all users' API keys, as well as see which API key was created by which user in which realm.Empty prompt:
Non-admin view
If the user only has the
manage_own_api_key
privilege then they'll see a list of only their own keys. User and Realm is excluded from the table because this information would be redundant.Empty prompt:
To test
To test with limited privileges
manage_security
,manage_api_key
, and/ormanage_own_api_key
).kibana_user
.