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

Authentication to Kibana using API Keys #56087

Closed
kobelb opened this issue Jan 28, 2020 · 8 comments
Closed

Authentication to Kibana using API Keys #56087

kobelb opened this issue Jan 28, 2020 · 8 comments
Assignees
Labels
enhancement New value added to drive a business result Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!

Comments

@kobelb
Copy link
Contributor

kobelb commented Jan 28, 2020

Fleet will be using API Keys to authenticate to Kibana. They will potentially be doing so when only the basic auth provider is enabled in Kibana. They'll need a way to authenticate themselves in these scenarios.

@kobelb kobelb added Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! enhancement New value added to drive a business result labels Jan 28, 2020
@elasticmachine
Copy link
Contributor

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

@kobelb
Copy link
Contributor Author

kobelb commented Jan 28, 2020

/cc @azasypkin potentially related to #53910

@azasypkin
Copy link
Member

azasypkin commented Feb 6, 2020

@kobelb do you know if it's acceptable to explicitly enable this functionality via kibana.yml when it's needed or it should be enabled automatically when Fleet is available (whatever it may mean)?


Just a very rough idea I'm writing PoC for right now is that we may have HTTPAuthenticationProvider (HTTP ----> the one that performs authentication using HTTP Authentication Framework via Authorization HTTP header) and it may be configured with xpack.security.authc.http:

xpack.security.authc.http:
  enabled: true
  autoSchemesEnabled: true
  schemes: [ApiKey]
  • xpack.security.authc.http.enabled - the plan for this to be true by default for the time being that will allow us to consolidate this functionality and move it from other providers to a new dedicated one.

  • xpack.security.authc.http.autoSchemesEnabled - not the best name, it's essentially a legacy fallback that will force HTTP provider to check which other providers are enabled and automatically include schemes to support them (e.g. basic for basic and bearer for kerberos, saml and friends). Should be true by default to support reporting.

  • xpack.security.authc.http.schemes - additional schemes we'd like to support.

@kobelb
Copy link
Contributor Author

kobelb commented Feb 6, 2020

@kobelb do you know if it's acceptable to explicitly enable this functionality via kibana.yml when it's needed or it should be enabled automatically when Fleet is available (whatever it may mean)?

If it's possible to avoid needing to set a kibana.yml setting, I think that would be ideal. As far as I'm aware, Fleet will always be "enabled". @elastic/ingest-management would you mind keeping me honest on this?

I like the direction you're going with the PoC, and I think it'd work perfectly for all other scenarios. Do you think it's possible for us to accept the Authorization: Bearer header on Fleet specific routes when autoSchemesEnabled is set to true? Or does that make everything convoluted?

@azasypkin
Copy link
Member

azasypkin commented Feb 7, 2020

Do you think it's possible for us to accept the Authorization: Bearer header on Fleet specific routes when autoSchemesEnabled is set to true?

Assuming you mean Authorization: ApiKey header: yeah technically we can do that too to simplify experience. Also since we're talking about API keys in many different aspects (e.g. for Reporting) I was thinking about having dedicated extended config just for API keys, but at the same time generalizing this feels a bit too premature, so leveraging legacy fallback option (autoSchemesEnabled) that we can later transform into something more specific sounds reasonable to me.

Or does that make everything convoluted?

It depends on how we frame it, if we have a good way to distinguish all necessary Fleet routes and whether we want to allow users to configure/disable this behavior or not.

@nchaulet
Copy link
Member

If it's possible to avoid needing to set a kibana.yml setting, I think that would be ideal. As far as I'm aware, Fleet will always be "enabled". elastic/ingest-management would you mind keeping me honest on this?

Yes we want fleet to be as easy to use as possible, so if we can avoid to have extra step to configure api key authorization it would be better

@kobelb
Copy link
Contributor Author

kobelb commented Feb 10, 2020

FWIW, in my previous comment I forgot that API Keys work with Authorization: ApiKey headers and not Authorization: Bearer headers. As far as I'm aware, Fleet won't be doing anything special with Authorization: Bearer headers that affect Aleh's proposed architecture in #56087 (comment)

@azasypkin
Copy link
Member

Summary: Authentication via Authorization: ApiKey xxxx is now supported by default and can be disabled with this configuration option:

# default is xpack.security.authc.http.schemes: [apikey]
xpack.security.authc.http.schemes: [] 

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 Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Projects
None yet
Development

No branches or pull requests

4 participants