Improve auditing for run-as #84394
Labels
Comments
|
Pinging @elastic/es-security (Team:Security) |
ywangd
added a commit
that referenced
this issue
Feb 28, 2022
API Key can run-as since #79809. There are places in the code where we assume API key cannot run-as. Most of them are corrected in #81564. But there are still a few things got missed. This PR fixes the methods for checking owner user realm for API key. This means, when API Keys "running-as" (impersonating other users), we do not expose the authenticating key ID and name to the end-user such as the Authenticate API and the SetSecurityUseringest processor. Only the effective user is revealed, just like in the regular case of a realm user run as. For audit logging, the key's ID and name are not exposed either. But this is mainly because there are no existing fields suitable for these information. We do intend to add them later (#84394) because auditing logging is to consumed by system admin instead of end-users. Note the resource sharing check (canAccessResourcesOf) also needs to be fixed, this will be handled by #84277
ywangd
added a commit
to ywangd/elasticsearch
that referenced
this issue
Feb 28, 2022
API Key can run-as since elastic#79809. There are places in the code where we assume API key cannot run-as. Most of them are corrected in elastic#81564. But there are still a few things got missed. This PR fixes the methods for checking owner user realm for API key. This means, when API Keys "running-as" (impersonating other users), we do not expose the authenticating key ID and name to the end-user such as the Authenticate API and the SetSecurityUseringest processor. Only the effective user is revealed, just like in the regular case of a realm user run as. For audit logging, the key's ID and name are not exposed either. But this is mainly because there are no existing fields suitable for these information. We do intend to add them later (elastic#84394) because auditing logging is to consumed by system admin instead of end-users. Note the resource sharing check (canAccessResourcesOf) also needs to be fixed, this will be handled by elastic#84277
elasticsearchmachine
pushed a commit
that referenced
this issue
Feb 28, 2022
* Fix owner user realm check for API key authentication (#84325) API Key can run-as since #79809. There are places in the code where we assume API key cannot run-as. Most of them are corrected in #81564. But there are still a few things got missed. This PR fixes the methods for checking owner user realm for API key. This means, when API Keys "running-as" (impersonating other users), we do not expose the authenticating key ID and name to the end-user such as the Authenticate API and the SetSecurityUseringest processor. Only the effective user is revealed, just like in the regular case of a realm user run as. For audit logging, the key's ID and name are not exposed either. But this is mainly because there are no existing fields suitable for these information. We do intend to add them later (#84394) because auditing logging is to consumed by system admin instead of end-users. Note the resource sharing check (canAccessResourcesOf) also needs to be fixed, this will be handled by #84277 * fix test
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Prior to 8.1, run-as is only supported for realm authenticated users. The audit log has the following fields for the authenticated user and the effective user:
user.run_by.nameuser.run_as.nameuser.run_by.realmuser.run_as.realmSince #79809 (8.2), an API key can also perform run-as. An API key has extra information like its ID and name. It also has both its own sythetic realm (
_es_api_key) and the ower's name and realm. In #84325, we mapped the API key owner's name touser.run_by.nameand the synthetic realm touser.run_by.realm. But we still need extra fields to map the API key's ID and name as well as its owner's realm.We should revisit and improve how auditing is done for the authenticated user and the effective user. The service account's name and type are logged under its own section (
authentication) separated from theuserfields. This was intentional because the intention is to have a separate section for authentication information. This is a potential candidate for expansion to accomodate the extra information for the API key.The text was updated successfully, but these errors were encountered: