Skip to content

Fix incorrect assumptions for api_key authentication type #81564

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

Merged
merged 11 commits into from
Jan 18, 2022

Conversation

ywangd
Copy link
Member

@ywangd ywangd commented Dec 8, 2021

This is essentially a follow-up PR for #79809 which enables run-as for API keys. The code still has a few places where it assumes API keys cannot perform run-as. This PR fixes the incorrect assumptions and adds relevant tests.

Resolves: #81425

Still need sweep through test code
Also add new tests
@ywangd ywangd added >non-issue :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC v8.1.0 labels Dec 8, 2021
@ywangd ywangd requested a review from tvernum December 9, 2021 03:14
@ywangd ywangd marked this pull request as ready for review December 9, 2021 03:14
@elasticmachine elasticmachine added the Team:Security Meta label for security team label Dec 9, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security (Team:Security)

@ywangd
Copy link
Member Author

ywangd commented Dec 9, 2021

@tvernum I was going to use AuthenticationContext for this PR. But then decided against it because there are quite a bit of changes and I don't want complicate the core changes with auxiliary ones. I think it's better to have a separate PR that just replaces Authentication with AuthenticationContext with no functional changes.

Copy link
Contributor

@tvernum tvernum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ywangd
Copy link
Member Author

ywangd commented Jan 17, 2022

@elasticmachine update branch

@ywangd
Copy link
Member Author

ywangd commented Jan 18, 2022

@elasticmachine run elasticsearch-ci/part-1-fips

@ywangd ywangd merged commit 223e375 into elastic:master Jan 18, 2022
ywangd added a commit to ywangd/elasticsearch that referenced this pull request Feb 24, 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.

Note the resource sharing check (canAccessResourcesOf) also needs to be
fixed, this will be handled by elastic#84277
ywangd added a commit that referenced this pull request 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 pull request 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 pull request 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
Labels
>non-issue :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC Team:Security Meta label for security team v8.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Review and correct checks for AuthenticationType.API_KEY
3 participants