Restrict run-as to realm and api_key authentication types #84336
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
This PR removes run-as support for authentication types other than realm and API key. The change essentially makes the behaviour closer to the existing one (in released versions) except for API keys. This is not to say that the existing behaviour is the best. But we need more time to agree on the new behaviour. Relates: elastic#79809
ywangd
added
>non-issue
:Security/Authentication
|
Pinging @elastic/es-security (Team:Security) |
ywangd
commented
Feb 27, 2022
Comment on lines
211
to
214
| logger.info( | ||
| "ignore run-as header since it is not supported for authentication type [{}]", | ||
| authentication.getAuthenticationType().name().toLowerCase(Locale.ROOT) | ||
| ); |
There was a problem hiding this comment.
Logging at INFO level instead of WARN to avoid causing unnecessary worries. Also didn't add warning to response header because I am not sure whether it would be another unpleasant experience in Kibana (warning message spamming in dashboard etc).
There was a problem hiding this comment.
Seems like a safe choice, but when we decide what to do in 8.2 we'll need to take into account that we've ignored the headers up until this point (without warning).
There was a problem hiding this comment.
Yes it's a tricky situation. Even supporting API key run-as in this release has this same issue. It's in a gray area of "breaking change" vs "bug fix" vs "feature". It's probably a stretch to call it a "bug fix" since we intentionally not supporting things like token. But I also really don't think it should be breaking. I'll tweak the logging message a little bit to say:
"... it is currently not supported ..." to indicate the support might be coming.
This subtlety might not be that useful. It is definitely not officical because it is not a proper deprecation message or anything. But we don't have such tooling right now. So some subtlety in the wording might be our best bet right now.
tvernum
approved these changes
Feb 27, 2022
Comment on lines
211
to
214
| logger.info( | ||
| "ignore run-as header since it is not supported for authentication type [{}]", | ||
| authentication.getAuthenticationType().name().toLowerCase(Locale.ROOT) | ||
| ); |
There was a problem hiding this comment.
Seems like a safe choice, but when we decide what to do in 8.2 we'll need to take into account that we've ignored the headers up until this point (without warning).
ywangd
added a commit
to ywangd/elasticsearch
that referenced
this pull request
Feb 28, 2022
Creating tokens using API keys is not properly supported till elastic#80926. Previously the created token always has no previlege. Now the token has the same privilege as the API key itself (similar to user created tokens). Authenticating using the token is considered equivalent to the API key itself. Therefore the "isApiKey" check needs to be updated to cater for both authentications of API key itself and the token created by the API key. This PR updated the isApiKey check and apply it consistently to ensure the behaviour is consistent between an API key and a token created by it. The only exception is for supporting run-as. API key itself can run-as another user. But a token created by the API key cannot perform run-as (elastic#84336) similar to how user/token works.
ywangd
added a commit
to ywangd/elasticsearch
that referenced
this pull request
Feb 28, 2022
) This PR removes run-as support for authentication types other than realm and API key. The change essentially makes the behaviour closer to the existing one (in released versions) except for API keys. This is not to say that the existing behaviour is the best. But we need more time to agree on the new behaviour. Relates: elastic#79809
ywangd
added a commit
that referenced
this pull request
Feb 28, 2022
…84399) This PR removes run-as support for authentication types other than realm and API key. The change essentially makes the behaviour closer to the existing one (in released versions) except for API keys. This is not to say that the existing behaviour is the best. But we need more time to agree on the new behaviour. Relates: #79809
ywangd
added a commit
that referenced
this pull request
Feb 28, 2022
Creating tokens using API keys is not properly supported till #80926. Previously the created token always has no previlege. Now the token has the same privilege as the API key itself (similar to user created tokens). Authenticating using the token is considered equivalent to the API key itself. Therefore the "isApiKey" check needs to be updated to cater for both authentications of API key itself and the token created by the API key. This PR updates the isApiKey check and apply it consistently to ensure the behaviour is consistent between an API key and a token created by it. The only exception is for supporting run-as. API key itself can run-as another user. But a token created by the API key cannot perform run-as (#84336) similar to how user/token works.
ywangd
added a commit
to ywangd/elasticsearch
that referenced
this pull request
Feb 28, 2022
Creating tokens using API keys is not properly supported till elastic#80926. Previously the created token always has no previlege. Now the token has the same privilege as the API key itself (similar to user created tokens). Authenticating using the token is considered equivalent to the API key itself. Therefore the "isApiKey" check needs to be updated to cater for both authentications of API key itself and the token created by the API key. This PR updates the isApiKey check and apply it consistently to ensure the behaviour is consistent between an API key and a token created by it. The only exception is for supporting run-as. API key itself can run-as another user. But a token created by the API key cannot perform run-as (elastic#84336) similar to how user/token works.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Feb 28, 2022
Creating tokens using API keys is not properly supported till #80926. Previously the created token always has no previlege. Now the token has the same privilege as the API key itself (similar to user created tokens). Authenticating using the token is considered equivalent to the API key itself. Therefore the "isApiKey" check needs to be updated to cater for both authentications of API key itself and the token created by the API key. This PR updates the isApiKey check and apply it consistently to ensure the behaviour is consistent between an API key and a token created by it. The only exception is for supporting run-as. API key itself can run-as another user. But a token created by the API key cannot perform run-as (#84336) similar to how user/token works.
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.
This PR removes run-as support for authentication types other than realm
and API key. The change essentially makes the behaviour closer to
the existing one (in released versions) except for API keys. This is not
to say that the existing behaviour is the best. But we need more time to
agree on the new behaviour.
Relates: #79809