Skip to content
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

Support getting active API keys #98259

Merged
merged 31 commits into from
Aug 9, 2023

Conversation

n1v0lg
Copy link
Contributor

@n1v0lg n1v0lg commented Aug 7, 2023

This PR adds a flag active_only to the Get API key API to optionally retrieve active-only (i.e., neither expired nor invalidated) API keys. The flag defaults to false, i.e., by default, expired and invalidate API keys are included in the response (therefore we keep BWC).

An example API call is:

GET /_security/api_key?active_only=true

The active_only flag can be used with realm and username based flags (e.g., active_only=true&username=X) as well as name and id. In the case it's used with id for an existing but non-active key the response code is 404. This is consistent with the owner flag behavior.

Closes #97995

@n1v0lg n1v0lg added >enhancement :Security/Security Security issues without another label v8.10.0 labels Aug 7, 2023
@n1v0lg n1v0lg self-assigned this Aug 7, 2023
@elasticsearchmachine
Copy link
Collaborator

Hi @n1v0lg, I've created a changelog YAML for you.

@elasticsearchmachine
Copy link
Collaborator

Hi @n1v0lg, I've updated the changelog YAML for you.

@n1v0lg
Copy link
Contributor Author

n1v0lg commented Aug 8, 2023

@elasticmachine update branch plz

@n1v0lg n1v0lg marked this pull request as ready for review August 8, 2023 16:41
@n1v0lg n1v0lg requested a review from ywangd August 8, 2023 16:41
@elasticsearchmachine elasticsearchmachine added the Team:Security Meta label for security team label Aug 8, 2023
@elasticsearchmachine
Copy link
Collaborator

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

@n1v0lg n1v0lg changed the title Support getting active-only API keys Support getting active API keys Aug 8, 2023
Copy link
Member

@ywangd ywangd left a comment

Choose a reason for hiding this comment

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

LGTM

Comment on lines +58 to +59
// Set short enough expiration for the API key to be expired by the time we query for it
final String apiKeyId2 = createApiKey(MANAGE_SECURITY_USER, "key-2", TimeValue.timeValueNanos(1));
Copy link
Member

Choose a reason for hiding this comment

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

I just realized that it is possible to set 0 for the expriation time or even -1, e.g. -1d! So technically we can make this "soon-to-expire" behaviour rock solid. That said, 1ns seems to be short enough and we might consider allowing 0 and -1 as a bug.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It does feel like a bug, good catch!

I haven't made up my mind yet about whether to fix it though. I can see some contrived scenario where customer is using 0--or maybe even negative values if they're doing some date math--in e.g., some automated test pipeline and changing this breaks things for them. This feels very far-fetched though.

On the other hand, the advantage of fixing this is also quite small.

The only "real" scenario that comes to mind where someone might be using 0 or -1 is if they're misinterpreting the API: expiration=0 or expiration=-1 could be interpreted as "never expire" -- if someone doesn't carefully read the docs, they might just assume that's what it means. But that's actually more of an argument for fixing the bug...

TL;DR: I'm leaning (slightly) towards treating this as a bug, without BWC implications, and just fixing it, but I want to sit on this for a bit and see if I come up with a reason not to. What would be your preference?

For this PR, I will leave the 1ns as is.

Copy link
Member

Choose a reason for hiding this comment

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

My preference is also treating it as a bug since I cannot think of any useful thing it can do. Definitely not critical though because the ultimate behaviour is correct, i.e. the API key cannot be used. We may also want to get the team's consensus on this.

@n1v0lg
Copy link
Contributor Author

n1v0lg commented Aug 9, 2023

@elasticmachine update branch

@n1v0lg n1v0lg added the auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) label Aug 9, 2023
@n1v0lg
Copy link
Contributor Author

n1v0lg commented Aug 9, 2023

@elasticmachine update branch

@elasticsearchmachine elasticsearchmachine merged commit edf47d2 into elastic:main Aug 9, 2023
@n1v0lg n1v0lg deleted the get-active-only-api-keys branch August 9, 2023 09:59
elasticsearchmachine pushed a commit that referenced this pull request Aug 10, 2023
elasticsearchmachine pushed a commit that referenced this pull request Dec 21, 2023
#98259 added a new flag for
the Get API key API. I missed adding it to the REST API spec originally.


This PR corrects the REST spec.
n1v0lg added a commit to n1v0lg/elasticsearch that referenced this pull request Dec 21, 2023
elastic#98259 added a new flag for
the Get API key API. I missed adding it to the REST API spec originally.


This PR corrects the REST spec.
elasticsearchmachine pushed a commit that referenced this pull request Dec 21, 2023
#98259 added a new flag for
the Get API key API. I missed adding it to the REST API spec originally.


This PR corrects the REST spec.

Co-authored-by: Elastic Machine <[email protected]>
navarone-feekery pushed a commit to navarone-feekery/elasticsearch that referenced this pull request Dec 22, 2023
elastic#98259 added a new flag for
the Get API key API. I missed adding it to the REST API spec originally.


This PR corrects the REST spec.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) >enhancement :Security/Security Security issues without another label Team:Security Meta label for security team v8.10.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

GET API Key API filter out expired and/or invalidated API keys
4 participants