I remember I made a fix such that all the auth_key* rules, try to compare both versions with plain-text username, and if fails it tries with hashed username and password.
So if you configure, either:
auth_key_sha256: cleartextUsername:encryptedPassword
auth_key_sha256: encryptedUsernameAndPassword
Thank you very much for this! I would have to inject a script before the startup of elasticsearch to do this user management.
Though I wish there would be better integration for Elastic’s official way of deploying on kubernetes (I wish not to modify the default image of Elasticsearch, as it would mean an additional thing to maintain)
We could actually implement this, if this, let’s see if the approach actually works!
Hi Simone,
I tried doing it the way you suggested; I wrote a piece of code which would go and fetch user:pass from the “config/users” file realm and put them in readonlyrest,yml. This worked perfectly as expected.
In even further discussion, I learnt about how the operator currently generates and uses the credentials for the internal users it creates.
The way I chose to go forward with was creating the secrets: [cluster]-es-elastic-user and [cluster]-es-internal-users with my own generated passwords for the 4 users the operator was using. This was done before creating the Elasticsearch cluster itself, so when operator found that the secrets already exist, it just used the existing ones without creating them again. And then I just put those username-password combinations in readonlyrest.yml using environment variable substitution.
This way I avoided putting any glue code inside the elasticsearch startup script. So, I don’t have to maintain a version of elasticsearch image which contains the above code.
Could we have a proposal for ROR to be able to run OOTB with the official elastic operator? I would leave it to you to decide which way you would want to implement this.
Great job! Yeah we could load that user file when we bring up the ACL. How about ROR reads the users file after ES startup? By then, ES should have written the user file, right?
Yes, the operator prepares the filesystem before running the main ES container. So, all the users are already there in the user file at the time of startup of ES.
Any possibility of having this included in v1.18.10? (Maybe we could have a config parameter which would enable/disable populating readonlyrest.yml from the elasticsearch/config/users file)
Yes we definitely could implement this, but 1.18.10 merge window is closed now, we will come back with a pre build for you after the release.
1.18.10 is already released 
I’m definitely watching this thread 
Hey @barryib, did you decide to manage your own kubernetes cluster in the end? Rather than getting the managed ES from AWS?
We’ve tested the AWS ES in production for one of our small service, but so far we aren’t happy with it. So we’re going to tests ECK with RoR in the next couple of weeks. We’ll decide after those tests which cluster we’ll shutdown.
Any updates on when OOTB compatability with ECK might be released? Running on kubernetes without the Elastic Operator is a bit like bread without butter, and we’d really like to retain RoR as part of our stack.
This is targeted for 1.19.3, we are about to release 1.19.2. We will share with you a pre-build you can test as soon as we have it!
Hi, any update on whether this has been implemented in some way in a pre-build, I notice the issue is still open on GitHub? 
Sorry Alex, it’s not ready yet because we have prioritised our efforts to bring ROR out of Elasticsearch so you won’t need to install it as a plugin in all nodes anymore. As a result it will be a stateless, ES protocol aware security aware HTTP proxy.
However, I just pused up this task to the top of the backlog. We’ll handle it in the next iteration.
Was this something that was able to be resolved?
I am trying the same thing and an unable to even disable security with 7.8.
Do you have an ETA for when it will be deployed and usable in this state? And will it secure both elastic and kibana still?
we will provide more info on this on Monday.