[TRANSFORM] Add authorization info to transform config listings#87570
[TRANSFORM] Add authorization info to transform config listings#87570droberts195 merged 10 commits intoelastic:masterfrom
Conversation
Transforms remember permissions from their time of creation or most recent update. It can be quite hard to determine what these are when listing transform configs, which can lead to uncertainty about whether some minor update changed the permissions. This change adds information about the permissions to the config listings. If the last update was from a user then the permissions used are the roles they had at the time, and a list of these roles is added to the new `run_as` field of the transform config listing. If the last update was using an API key then the permissions of that API key are used for subsequent transform operations, and the new `run_as` field of the transform config listing shows the API key name and ID. If a service account did the last update then the service account name is added to the new `run_as` field of the transform config listing.
|
Hi @droberts195, I've created a changelog YAML for you. |
|
Pinging @elastic/es-security (Team:Security) |
|
Pinging @elastic/ml-core (Team:ML) |
| if (authKey == null) { | ||
| return; | ||
| } | ||
| builder.startObject(RoleDescriptor.Fields.RUN_AS.getPreferredName()); |
There was a problem hiding this comment.
I think it's better to find a different name for this field. run_as in RoleDescriptor as a specific meaning for user impersonation, which includes an authenticating user and an effective user. It is also a previlege that user can configure when creating a role. For the use case here, maybe something more generic like authorization could be better?
dimitris-athanasiou
left a comment
There was a problem hiding this comment.
Just a question about renaming the method. Also, please make sure to update the PR + the changelog message to reflect the added field is authorization and not run_as.
.../plugin/core/src/main/java/org/elasticsearch/xpack/core/security/xcontent/XContentUtils.java
Outdated
Show resolved
Hide resolved
...in/core/src/test/java/org/elasticsearch/xpack/core/security/xcontent/XContentUtilsTests.java
Outdated
Show resolved
Hide resolved
| Subject authenticationSubject = AuthenticationContextSerializer.decode(authKey).getEffectiveSubject(); | ||
| switch (authenticationSubject.getType()) { | ||
| case USER -> builder.array(User.Fields.ROLES.getPreferredName(), authenticationSubject.getUser().roles()); | ||
| case API_KEY -> { |
There was a problem hiding this comment.
Don't we need break; statements after each case?
There was a problem hiding this comment.
No, break statements aren’t used with the modern switch syntax that uses -> for each case. Only the expression immediately after the -> is executed for each case (which can be a code block in braces).
There was a problem hiding this comment.
Ok, thanks. I missed that this is the new syntax.
| Subject authenticationSubject = AuthenticationContextSerializer.decode(authKey).getEffectiveSubject(); | ||
| switch (authenticationSubject.getType()) { | ||
| case USER -> builder.array(User.Fields.ROLES.getPreferredName(), authenticationSubject.getUser().roles()); | ||
| case API_KEY -> { |
There was a problem hiding this comment.
Ok, thanks. I missed that this is the new syntax.
…88052) In #87570 authorization info was added to transform listings. Authorization information was also implicitly added to transform update responses. However, YAML tests were not added to either. This PR adds some assertions to the YAML tests for getting transforms and transform updates to prove that the responses really do include authorization information.
Transforms remember permissions from their time of creation
or most recent update. It can be quite hard to determine what
these are when listing transform configs, which can lead to
uncertainty about whether some minor update changed the
permissions.
This change adds information about the permissions to the
config listings.
If the last update was from a user then the permissions used
are the roles they had at the time, and a list of these roles
is added to the new
authorizationfield of the transform configlisting.
If the last update was using an API key then the permissions
of that API key are used for subsequent transform operations,
and the new
authorizationfield of the transform config listingshows the API key name and ID.
If a service account did the last update then the service
account name is added to the new
authorizationfield of the transformconfig listing.