-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Support getting active API keys #98259
Conversation
Hi @n1v0lg, I've created a changelog YAML for you. |
Hi @n1v0lg, I've updated the changelog YAML for you. |
x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/ApiKeyService.java
Show resolved
Hide resolved
x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/ApiKeyService.java
Show resolved
Hide resolved
@elasticmachine update branch plz |
...ty-trial/src/javaRestTest/java/org/elasticsearch/xpack/security/apikey/GetApiKeysRestIT.java
Show resolved
Hide resolved
…earch into get-active-only-api-keys
Pinging @elastic/es-security (Team:Security) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
// 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)); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
...ty-trial/src/javaRestTest/java/org/elasticsearch/xpack/security/apikey/GetApiKeysRestIT.java
Show resolved
Hide resolved
x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/ApiKeyService.java
Show resolved
Hide resolved
@elasticmachine update branch |
@elasticmachine update branch |
#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.
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.
#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]>
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.
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:
The
active_only
flag can be used with realm and username based flags (e.g.,active_only=true&username=X
) as well asname
andid
. In the case it's used withid
for an existing but non-active key the response code is 404. This is consistent with theowner
flag behavior.Closes #97995