Elastic Password with Docker and TLS

Hi, I'm trying to setup an elasticsearch service running inside a docker container, first in my local machine to make everything work right before I try to deploy remotely.

The problem is that I set the ELASTIC_PASSWORD environment variable, as well as a self-signed certificate + key + ca, but when I try to curl using the username elastic and the password provided, an error occurs (of unauthenticated user).

Among other things I did:

  1. I made sure that the ELASTIC_PASSWORD variable is correct (entering the container and running printenv | grep ELASTIC_PASSWORD).
  2. In the curl command, the user, password, endpoint and certificate provided are correct.
  3. I cleared the elasticsearch database and started again (because I assume ELASTIC_PASSWORD only works the first time). In any case, to no avail.
  4. If i run ./bin/elasticsearch-setup-passwords interactive to define the password, it returns an error saying that the ip is not in the subject alternative names of the (self-signed) tls certificate (which is correct).
  5. If i run ./bin/elasticsearch-setup-passwords interactive --url https://elasticsearch:9200 it works, I can define the elastic password, and then I can access with curl from outside the container (which is what I wanted from the beginning).

I don't know why the ELASTIC_PASSWORD environment variable haven't worked, maybe it's because of the same problem that caused the elasticsearch-setup-passwords command to fail if not passing the url, but in any case I see no error logs about it. Also, I haven't found other users with this problem. I'm using the elasticsearch 7.5.0 official image.

Is there a way to make the ELASTIC_PASSWORD work? Or, alternatively, is there some way to automate elasticsearch-setup-passwords to run non-interactivelly from a script to define only the elastic password?


Here is how I'm setting that with docker compose ( docker-compose.yml):

version: '3'

    image: docker.elastic.co/elasticsearch/elasticsearch:$ELASTIC_VERSION
      - bootstrap.memory_lock=true
      - discovery.type=single-node
      - xpack.security.enabled=$ELASTIC_SECURITY
        soft: -1
        hard: -1
      - 9200:9200
    networks: ['stack']

    image: docker.elastic.co/kibana/kibana:$ELASTIC_VERSION
    ports: ['5601:5601']
    networks: ['stack']
    links: ['elasticsearch']
    depends_on: ['elasticsearch']

  stack: {}

.env file is:


Hope this could help...

1 Like

It seems the cause is because I'm using secrets with ELASTIC_PASSWORD_FILE instead of ELASTIC_PASSWORD.

I thought they were equivalent. Furthermore, I had this problem before and tried to use the environment variable ELASTIC_PASSWORD directly but it didn't work, so I haven't tried again (maybe I commited a mistake when I tried before, like not recreating the container, or I executed the whole process that generates the docker compose file from a template using ansible and the temporary changes were overwritten, I'm not sure now).

But just to be sure, I tried again now and it worked.

So, it seems like using a file as a secret is not supported? I tried using the secret both with and without a newline at the end. Here is the exact output inside the container:

[root@elasticsearch elasticsearch]# printenv | grep ELASTIC_PASSWORD_FILE
[root@elasticsearch elasticsearch]# cat /run/secrets/elastic_password
[root@elasticsearch elasticsearch]# 

Is there something I'm overlooking? I used the secret as defined at:

Did you bind mount the file? I guess you did.

It should work as documented but I never tried this option myself.

Maybe someone else knows?

I used docker-compose with the secrets option, and the file was included successfully in the container (as you can see in the output of the command from my previous post).

Maybe there's some issue regarding permissions? Although I successfully accessed the value from inside the container, which is expected because I'm root in the container. Maybe elasticsearch does something in the entrypoint to change the user to a non-root and tries to load the secret after that? I have not seen anything saying about it, tough, in the documentation I linked before.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.