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)
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.
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.
we have just released ROR 1.50.0 with ECK support.
You have to enable xpack security (xpack.security.enabled: true ) and patch Elasticsearch after installing ROR. Moreover, you have to use xpack security SSL for HTTP and transport.
We were in a hurry to merge ECK support because that branch was rapidly diverging from the main one.
Our pilot customer was already sufficiently happy with ROR+ECK, so we decided to merge it and continue working on the main branch.
As a result, the code is out, but the truth is that the tooling and documentation still does not make the feature usable.
We can do two things:
prioritize further ECK examples simplification & documentation
Follow up with you @rjan on ECK guidance as a support request
