Perceived catch-22 during bootstrap of default passwords

[martinr_ubi (Martin R.)]

Hi,

Currently running 5.4.3 dockerized (official images+ec2 disco plugin) on AWS Container Service (ECS).

There is something I don't understand about best practices for bootstrapping the security aspect of xpack.
(Currently trying to become a licensed customer so I won't disable xpack.)

Documentation
Documentation
Explain that you should issue API calls after first boot to change the default passwords for the following users:
elastic,kibana,logstash_system

This second link also says to disable default password support:
xpack.security.authc.accept_default_password: false

The full text is:

Once you have changed the password for the built-in users, you should disable default password support by setting xpack.security.authc.accept_default_password to false.

Future releases will require that default passwords are disabled in production mode.

So from all that I understand that the only way to change the default password of "changeme" is to issue API calls after ES is running. I can't do that before ES is running directly in the docker image or via configuration. They are stored in .securty index so I get it.

I also understand that setting,
xpack.security.authc.accept_default_password: false
through env var as with all my other setting when I define my docker service will make the 3 built-in users unusable.
Also note that future releases will require this to be false at launch time if triggering production mode, so soon I WILL have to disable that from the get go when defining my docker env var or I will not pass the production checks.

The perceived catch-22 is this:
I launch ES with:
xpack.security.authc.accept_default_password: false
set through docker env var.
ES has never run, default password are still changeme but they are disabled... so I can't use them to replace "changeme" with something else. I essentially can't login to my brand new cluster.

Now one might say the solution is easy... don't set:
xpack.security.authc.accept_default_password: false
to false on the first start.... change the default passwords, then set it to false and reboot.

Problem is:

1. To me that's weird because I'm trying to automate and that's awfully manual, I'd need to redeploy my container definition with new env vars.
2. Future releases will require that default passwords are disabled in production mode.... and I launch in production mode... so default passwords will be disabled even on the first es startup when triggering production mode.

So in production mode... or if I really dislike the idea of having to run ES with certain env var then change them and redeploy my docker I'm locked out of the native realm from the get go.

Only way out I see is to use the file realm to create a superuser (I CAN probably do that before ES start in my docker file, don't see why not.) and then there is a functional user for which I know the password and I can use it to start issuing bootstrapping command to my ES cluster after it's running.
I could reset the password for elastic,kibana and logstash_system... etc.

What am I not getting?

• I want my first startup of ES to be done with the same configuration as all the subsequent startup. first run only config are kinda hard to orchestrate with dockerized services.
• I want to respect security best practices as much as possible.
• I want to be ready for when xpack.security.authc.accept_default_password: false is needed to pass production mode checks.

How do I bootstrap xpack security or how do I bake it in the image?

Martin

[TimV (Tim Vernum)]

Future releases will require that default passwords are disabled in production mode.

When this document was written, our plan was to enforce that the "accept_default_password" configuration setting was set to false in production mode.
We have actually taken a bigger step than that, and as of 6.0-beta1, we have removed default passwords completely.
I have pushed a change to remove that text from the 5.5 docs, as it is now very misleading (it hasn't made it to the live site as I write this, but it will soon).

The new password setup process was designed in consultation with our internal docker team, so we are confident that it should suit your needs within AWS-ECS.

So, don't worry too much about the future releases mentioned in that doc, or if you do want to worry, read about how we handle it in 6.0-beta1 and then pass on any feedback you have.

Only way out I see is to use the file realm to create a superuser (I CAN probably do that before ES start in my docker file, don’t see why not.)

Yes. If you need to have a 100% automated deployment of Elastisearch 5.x straight into production mode, without any default passwords, then the file realm is the way to do that.
If I recall correctly, that is how our official docker images worked in the 6.0-alpha series.