Improve auditing of API key authentication #58928
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
albertzaharovits
added
>enhancement
:Security/Audit
|
Pinging @elastic/es-security (:Security/Audit) |
albertzaharovits
commented
Jul 2, 2020
...n/core/src/main/java/org/elasticsearch/xpack/core/security/authz/permission/LimitedRole.java
Outdated
Show resolved
Hide resolved
albertzaharovits
commented
Jul 5, 2020
| Runnable action = () -> { | ||
| logger.trace("Established authentication [{}] for request [{}]", authentication, request); | ||
| listener.onResponse(authentication); | ||
| }; | ||
| try { | ||
| authenticationSerializer.writeToContext(authentication, threadContext); | ||
| request.authenticationSuccess(authentication); | ||
| } catch (Exception e) { |
There was a problem hiding this comment.
Moving the auditing of authentication_success down here avoids the unlikely, but confusing case of authentication_success followed by authentication_failed.
albertzaharovits
commented
Jul 5, 2020
| user = new User("hulk", new String[] { "superuser" }, new User("authenticated_user", new String[] { "other" })); | ||
| } else { | ||
| user = new User("hulk", new String[] { "superuser" }); | ||
| } |
There was a problem hiding this comment.
mix-in creating an API Key while running-as.
albertzaharovits
added a commit
that referenced
this pull request
Jul 9, 2020
1. Add the `apikey.id`, `apikey.name` and `authentication.type` fields to the `access_granted`, `access_denied`, `authentication_success`, and (some) `tampered_request` audit events. The `apikey.id` and `apikey.name` are present only when authn using an API Key. 2. When authn with an API Key, the `user.realm` field now contains the effective realm name of the user that created the key, instead of the synthetic value of `_es_api_key`.
albertzaharovits
added a commit
that referenced
this pull request
Jul 23, 2020
This PR describes the new audit entry attributes api_key.id, api_key.name and authentication.type, as well as the meaning of existing attributes when authentication is performed using API keys. This should've been part of #58928
albertzaharovits
added a commit
that referenced
this pull request
Jul 23, 2020
This PR describes the new audit entry attributes api_key.id, api_key.name and authentication.type, as well as the meaning of existing attributes when authentication is performed using API keys. This should've been part of #58928
albertzaharovits
added a commit
that referenced
this pull request
Jul 23, 2020
This PR describes the new audit entry attributes api_key.id, api_key.name and authentication.type, as well as the meaning of existing attributes when authentication is performed using API keys. This should've been part of #58928
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These changes roughly follow #52551 (comment) after some course correct.
apikey.id,apikey.nameandauthentication.typefields to theaccess_granted,access_denied,authentication_successand (some)tampered_requestaudit events (apikey.idandapikey.nameare present only when authn with an API Key)user.realmfield now contains the realm name of the user that created the key, instead of the synthetic value of_es_api_key. Note that in this circumstance, theuser.namefield reflects the name of the user that created the key (they are consistent)user.rolescontains the role names (only of found/resolved roles) of the user that created the key. It previously wrongly had the role descriptor names from the API key definition.Relates #52551