Skip to content
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

Open
n0othing opened this issue Mar 3, 2021 · 4 comments
Open

Support PKI auth against Kibana APIs #93452

n0othing opened this issue Mar 3, 2021 · 4 comments
Labels
enhancement New value added to drive a business result Feature:Security/Authorization Platform Security - Authorization Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!

Comments

@n0othing
Copy link
Member

n0othing commented Mar 3, 2021

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.

@n0othing n0othing added enhancement New value added to drive a business result Feature:Security/Authorization Platform Security - Authorization labels Mar 3, 2021
@azasypkin azasypkin added the Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! label Mar 9, 2021
@elasticmachine
Copy link
Contributor

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

@mbarretta
Copy link

mbarretta commented Apr 7, 2021

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

@legrego
Copy link
Member

legrego commented Jun 1, 2021

@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 #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
Copy link
Contributor

tvernum commented Jun 2, 2021

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.

@exalate-issue-sync exalate-issue-sync bot added impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort labels Aug 5, 2021
@exalate-issue-sync exalate-issue-sync bot added impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. and removed impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. labels Nov 23, 2021
@legrego legrego removed EnableJiraSync loe:small Small Level of Effort impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. labels Aug 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New value added to drive a business result Feature:Security/Authorization Platform Security - Authorization Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Projects
None yet
Development

No branches or pull requests

6 participants