-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Implement lookup of permissions for API keys #35970
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
Implement lookup of permissions for API keys #35970
Conversation
This change implements a lookup of permissions for API keys when a request moves to authorization. In order to support this, the authentication of an API key will attach values as metadata on the authentication result. The values attached will include the source of the role descriptors. The authentication service will then copy this metadata to the authentication object and set the authentication type to API_KEY. The authorization service will use the authentication type to make a decision on how the roles should be obtained.
Pinging @elastic/es-security |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I much prefer this approach to the one that created named roles.
x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/ApiKeyService.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
public enum AuthenticationType { | ||
REALM, | ||
API_KEY, | ||
TOKEN |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it worth adding ANONYMOUS
as an option here?
I think the current behaviour will treat it as REALM
which isn't quite right.
Happy to see it in a follow up PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it is. I think there can be some other values as well. Will address in a followup
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, had a comment on the caching of role which if desirable we can do it in next PRs. Thank you.
|
||
rolesStore.buildRoleFromDescriptors(roleDescriptorList, fieldPermissionsCache, ActionListener.wrap(role -> { | ||
threadContext.putTransient(API_KEY_ID_KEY, apiKeyId); | ||
threadContext.putTransient(API_KEY_ROLE_KEY, role); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see this as caching the built role similar to what we do in CompositeRolesStore
(roleCache
where we cache the role against the set of role names). But here we are keeping it in the ThreadContext
as transient, I was wondering if it would be helpful to or desirable to have a cache similar to what we have in CompositeRolesStore
?
We can enhance this if required in next PRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we discussed, this is not equivalent to caching and caching is superior so we'll want to do that.
This change builds upon the work done in elastic#35970 and adds appropriate types for anonymous and internal authentication to the `AuthenticationType` enum.
This change builds upon the work done in #35970 and adds appropriate types for anonymous and internal authentication to the `AuthenticationType` enum.
This change implements a lookup of permissions for API keys when a
request moves to authorization. In order to support this, the
authentication of an API key will attach values as metadata on the
authentication result. The values attached will include the source
of the role descriptors. The authentication service will then copy
this metadata to the authentication object and set the authentication
type to API_KEY. The authorization service will use the authentication
type to make a decision on how the roles should be obtained.