search

elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.81k stars 8.2k forks source link

Support PKI auth against Kibana APIs #93452

Open n0othing opened 3 years ago

n0othing commented 3 years ago

Describe the feature:

https://github.com/elastic/kibana/pull/82817 introduced a change that makes it difficult (if not impossible, depending on the use case) to use PKI to authenticate against Kibana's various APIs.

Some users may want to avoid HTTP auth (e.g username/password, API keys, etc) and rely on PKI so it'd be helpful to officially support it.

elasticmachine commented 3 years ago

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

mbarretta commented 3 years ago

Created this Beats issue to update the docs, which have PKI examples in numerous places

legrego commented 3 years ago

@elastic/es-security when we authenticate a user via the pki realm today, we call the Delegate PKI Authentication API to exchange the client certificate for an Elasticsearch access token. The access token is then used for all subsequent requests to ES when we need to authenticate as the end user.

This works great for our session-based consumers (e.g. logging in via web browser), but not so well for API-based consumers (such as Beats). Our API consumers have no need to maintain a session, and exchanging the cert for a token feels like overkill in this scenario, since it will not be used outside the scope of that request.

With that background, my question to you is: am I overly concerned about the cost of creating a token per API request? We prevented this behavior in https://github.com/elastic/kibana/pull/82817, but we can explore a revert if this turns out to be the best path forward.

Are there alternatives we can explore for authenticating users via the PKI realm without the token exchange?

This similarly applies to the kerberos realm, but it seems there is more interest in solving this for pki if we have to prioritize one over the other.

tvernum commented 3 years ago

am I overly concerned about the cost of creating a token per API request?

I think that is something we should be concerned about. Tokens are not so cheap that we can just cross our fingers and hope it works. We'd need to think about what sort of volumes are likely, and how that would perform.

Beats installing visualizations on startup is pretty low impact, but universal API access via PKI where the underlying cost is high, but hidden concerns me.

Are there alternatives we can explore for authenticating users via the PKI realm without the token exchange?

Yes. We know we want to support PKI via proxies, and that won't be token based, so I think we should plan for that to be a single solution that works for proxy access to ES APIs and direct (or possibly proxy) access to Kibana APIs.