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.)
This second link also says to disable default password support:
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,
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:
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:
to false on the first start.... change the default passwords, then set it to false and reboot.
- 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.
- 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?