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

setup-passwords causes confusion around the purpose of builtin users #29892

Open
elasticmachine opened this issue Mar 22, 2018 · 6 comments
Open
Labels
>enhancement :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) Team:Security Meta label for security team

Comments

@elasticmachine
Copy link
Collaborator

Original comment by @tvernum:

The problem is that once a customer runs setup-passwords they're given the userids and passwords for 3 users that can be quite misleading.

Since releasing setup-passwords in 6.0, we've seen an (anecdotal) increase in the number of customers who are using kibana to login to Kibana and logstash_system for their logstash pipelines.
And it makes sense that if users don't read the docs thoroughly, and they run the required tool and it gives them 3 users+passwords, then they'll go and use those users.

Possible solutions:

  • Docs (but we have docs, so we'd need to do something fundamentally better/different than what we have now)
  • More explicit output in the tool (possibly pointing to docs)
  • Setup more users in the tool? If we added an option to create personal users as well, then that might guide people through the process. Do you want to setup some logins for Kibana? Do you want to setup a user for logstash pipelines?. I think it's hard to do well, but it's an option.
@elasticmachine
Copy link
Collaborator Author

Original comment by @tvernum:

// CC: @elastic/es-security

@elasticmachine
Copy link
Collaborator Author

Original comment by @jkakavas:

My gut feeling is that

More explicit output in the tool

would be the lesser evil.

Docs (but we have docs, so we'd need to do something fundamentally better/different than what we have now)

In this case, I think it's more of a "users might not read documentation" problem than a "documentation is not clear enough" one.

Since this is ( I think ) mostly about users attempting to login to Kibana with the kibana user, should we revisit the discussion about renaming kibana to kibana_system that was started in LINK REDACTED ? ( I added the :Discuss label to that one while re-triaging and labeling before seeing this issue)

@elasticmachine
Copy link
Collaborator Author

Original comment by @tvernum:

Since this is ( I think ) mostly about users attempting to login to Kibana with the kibana user

Mostly, but not entirely. The issue was prompted by a forum post where logstash_system was being used in a pipeline, so while the "system" suffix will probably help, it's not the whole solution

@elasticmachine
Copy link
Collaborator Author

Original comment by @albertzaharovits:

Here's my 2 cents:

  • recommend setup-password auto mode instead of manual. It is auto in the guide but manual in the reference. The idea is that a long auto-generated password should discourage humans to use them.
  • generate a kibana_admin human friendly user, that can add other users and read anything (kibana_user role) and recommend it in the installing kibana-xpack
  • Drop a line about the purpose of these users (kibana and logstash_system), ie config entries were they should go, eg. elasticsearch.username inside kibana.yml. I would not link to docs, I fear links could get stale.

@elasticmachine
Copy link
Collaborator Author

Original comment by @bizybot:

All good ideas, sharing an alternative here.

As this is like an app to app communication that we want to authenticate, why not use certificate-based authentication.

  1. This is clear during the setup that these certificates are for the machine to machine communication.
  2. Users would not be able to use them traditionally like user/password so no accidental usage.

This would involve enabling client_authentication on during setup not sure of the work on the client side (like kibana, logstash) to use certs instead of configured credentials.
Plus there is this certificate management, but IMO this seems right to me than using passwords, as this is more explicit about the usage.

@elasticmachine
Copy link
Collaborator Author

Original comment by @tvernum:

As this is like an app to app communication that we want to authenticate, why not use certificate-based authentication.

We need to do a better job of making certificate-based auth easier for customers to use but the issues are:

  • We currently don't mandate TLS on the HTTP port
  • Certificates are hard to do well, and scare customers.
  • It just moves the problem from "here's a password for logstash, but only for monitoring" to "here's a cert for logstash, but only for monitoring". It helps with Kibana, but I don't have any reason to believe it helps with logstash.

@elasticmachine elasticmachine added :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) >enhancement labels Apr 25, 2018
@rjernst rjernst added the Team:Security Meta label for security team label May 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>enhancement :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) Team:Security Meta label for security team
Projects
None yet
Development

No branches or pull requests

2 participants