-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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 PKI auth against Kibana APIs #93452
Comments
Pinging @elastic/kibana-security (Team:Security) |
Created this Beats issue to update the docs, which have PKI examples in numerous places |
@elastic/es-security when we authenticate a user via the 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 #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 |
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.
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. |
Describe the feature:
#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.
The text was updated successfully, but these errors were encountered: