For our use case we are using a security plugin "readonlyrest". It seems the elastic operator is not compatible with this plugin OOTB. The requests being made by the operator is being blocked by this plugin, and I see 401 unauthorized errors in the logs.
Is it possible for us to configure the credentials being used by the elasticsearch-client within the operator when it tries to connect to the elasticsearch cluster?
This is a complete blocker for us, and it's not easy to identify the operator pod (by IP or otherwise) so that we can grant admin access to the cluster to only the operator. But what we can do is configure a set of credentials for the operator in our clusters and pass those credentials to the operator (provided there is a way the operator accepts them).
ECK uses several different sets of credentials for managing an Elasticsearch cluster and currently we don't provide a way for the users to override them. I am not familiar with the third-party plugin you mention so I can't give any specific instructions here. You could potentially try white-listing the elastic-internal and elastic-internal-keystore file realm users if the plugin allows it.
Unfortunately the plugin does not support file realm users. It would be great if users are allowed to configure the users and passwords being created by the operator in a future update.
If I understand correctly, this plugin disables xpack security and takes over the user management of Elasticsearch? If that's the case, I think you might have to re-create the operator accounts using the plugin and give them exactly the same passwords as the operator generated passwords stored in [cluster]-es-elastic-user and [cluster]-es-internal-users secrets. Please note that this is not something we recommend you do in production and the behaviour could change without notice in the future.
I will raise an issue to discuss the possibility of allowing user-defined credentials in a future release.
Also, could you tell if the secrets are created before or after the elasticsearch pods are created? As I could only mount the secrets to the pods as env vars if they are present before the pod is created
Administration tasks such as cluster orchestration, health checks and secure settings management are carried out by internal users and the elastic user is used for external access by other stack applications.
If you are trying to override the passwords for ECK users, you should create the corresponding Kubernetes secret before the cluster is created. See https://github.com/elastic/cloud-on-k8s/issues/967. Please note that this is a workaround and not an officially supported feature.
Thanks for all the help so far. I'm stuck here though: how do I get the ownerReference UID of the Elasticsearch custom resource before it has been created by the operator?
Also, would it be possible for me to re-set the passwords of all the 4 users afterwards by using the elasticsearch-users tool? Or would it overridden by the values present in the secrets?
I'm just trying to explore all the possible ways to workaround this issue (though I would prefer a solution without having to inject some code in to the Elasticsearch image)
You don't need the owner reference. If the [cluster]-es-internal-users secret exists with the correct entries in the data section, ECK will use that secret.
Because secrets are mounted as read-only volumes, I doubt the elasticsearch-users tool can be used but I have not tried to use it that way and can't give you a definite answer.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.