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

[albertzaharovits]

Description

The Get API key information API can currently filter the returned keys by:

• key id/name
• keys owned by the calling user
• keys owned by other users, by realm_name and username

Irrespective of the filtering used, both invalidated and expired (but not yet deleted) keys will be included in the response.
In the response, keys have the invalidated boolean property, as well as the expiration property that contains the UNIX timestamp past of which the key is no longer valid for authentication.

I propose we introduce a way for the API to support retrieving:

• only valid API keys (not return invalidated keys) - using a boolean request parameter
• keys not expired before a certain timestamp - using a timestamp parameter that defaults to "now" - also note that keys' experiation date is always checked against the local node's clock

[elasticsearchmachine]

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

[albertzaharovits]

CC @shasts @lloydmeta

[n1v0lg]

Overall in favor of this -- I think it's a very natural extension to the API.

qq @shasts @lloydmeta for your concrete use case: do you care about distinguishing between expired vs. invalidated API keys? To me a good abstraction here would be to filter out "inactive" API keys, i.e., add a flag like include_active_only (naming TBD) that would return API keys that are neither invalidated, nor expired.

[albertzaharovits]

We discussed it and the team is broadly in favor of it.
One aspect that was brought up in the conv, which is what Nikolaj is referring to in the above, is whether we need to expose the separation between expired and invalidated keys in the APIs interface.

Other questions of the same type, that can help us decide the interface change to the API:

• do we foresee the API being used to show only invalidated or only expired keys?
• do we foresee the API being used to show API keys that will expire at some specific time in the future/past?

The include_active_only boolean parameter is neat and simple, my only worry is that it can become unclear when used in conjuction, if we also end up with parameters for invalidated and/or expiration in the future.

[lloydmeta]

Good question; I don't think we really care about distinguishing between expired vs invalidated, so something like include_active_only makes sense to me.

For the most part, we've switched over to the Query API keys API, and IMO can rely on that if we find really need to make a distinction.

[n1v0lg]

Thanks @lloydmeta -- that was my thinking as well: the Query API is suited for more granular queries -- the Get API gives you more basic, abstracted functionality. FWIW, even if we decide to later add individual filter flags, we could add validation to ensure that include_active_only isn't used in bogus combination with these (e.g., include_active_only=True&invalidated=True or similar) or just address this in docs.

I don't think we will need this though -- to me the important bit is giving users the ability to fetch active API keys; for further drilling down on the data they can leverage the Query API. There would be some complexity in adding support for expiration in particular: to stay backwards compatible we would need to exclude this filter so we can't simply default to now for it. Nothing too challenging, I just prefer the simplicity of include_active_only here.

[albertzaharovits]

include_active_only ++