[API Keys] Last used

[roncohen]

One of the advantages of API Keys to manage access control is that they are cheap to create and maintain, so you often end up creating several of them.

To aid in manage them, it's very useful to know when an API Key was last used.

Other systems have this kind of feature and it proves indispensable in maintaining tight access control and good API Key hygiene. Without last used, retiring an API Key can be problematic and users will often postpone doing it because they cannot determine the ramifications.

[jasontedor]

@roncohen What level of resolution would you think is appropriate here? For example, is hourly okay? Without this, we end up making an update on every access, which would become expensive.

[elasticmachine]

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

[roncohen]

@jasontedor I think hourly as a start would be perfectly fine. Even daily, if that helps.

[bytebilly]

@roncohen there are a few questions that may help to better understand the use case and how this feature can contribute to Fleet.

Updating the timestamp on each request could have bad performance implications, and updating it on a timely basis (e.g. every 24h) sounds a bit strange to me.
I see feasible that users are fine seeing (2 days ago, 4 months ago, etc), but I suspect the precision of the timestamp should be at least minutes, since it makes sense for the immediate. If I'm monitoring an active agent, I want to know if it connected a minute ago or 5 hours ago.

In general, which is a good interval to consider an API key "dismissed"? Since they can be used on endpoints, the uptime is very difficult to predict.

This is what I envision in the Fleet use case: users are looking at the dashboard where agents are listed, and they want to know if agents are still active or if they suffered major problems and so need maintenance (e.g. cannot connect). Is this the user problem that we want to solve?

In this case, I suppose that we want to track the management connection rather than the ingest connection. Or even better, track the Agent status since there should be no need for users to deal with API keys directly.

Does it make sense to you?

[graphaelli]

In APM, API Keys are used to verify agent access to APM Server capabilities - they are application keys with no Elasticsearch cluster or index privileges. In this case, users directly deal with API keys and would benefit from having last used information for various reasons, but primarily as a check on their key rotation processes, to provide confidence that a particular key can be disabled.

Updating the timestamp on each request could have bad performance implications, and updating it on a timely basis (e.g. every 24h) sounds a bit strange to me.

For APM, we're flexible on this. Github personal access tokens provide week granularity - a newly used one says Less than a week ago, I admit one of mine says Less than 11 months ago - I should probably disable it. Just a hunch for now, but I expect daily granularity would be plenty for the APM use case.

[roncohen]

@bytebilly This request isn't really related to Fleet.

In Fleet we are already keeping track of "last seen" etc. and because we have one API Key per agent to ingest data into Elasticsearch we can build a good user experience around managing Agents instead of API Keys.

This is a general feature that as a user I'd want to have in order to be able to better manage my API Keys. I think @graphaelli did a great job on explaining the use case for APM. Another example is if I as a user build a custom application, I'd want to use API Keys to connect to Elasticsearch. Here it would also be useful to be able to see which keys are still being used.

since it makes sense for the immediate

I don't know what you mean by this.

[bytebilly]

Thanks both for your feedback, as discussed in the meeting we are not considering this as a blocker for Fleet but we'll investigate more in the future.