[docker] support _FILE environment variable

[jbudz]

Transferring from https://github.com/elastic/kibana-docker/issues/139

We are trying to run Kibana in DDC (sigh) and the secrets are mounted as files, and thus the "secret" has to be read from /run/secrets/secret-name. The "workaround" for this issue in DDC is to create a wrapper script that reads the secret and puts the value into the correct env variable.

I propose that the "helper" script could look for SOME_VAR_FILE, and if it finds that (and its a file thats readable), put the contents of the file into SOME_VAR.

The places I see this being most useful is "ELASTICSEARCH_PASSWORD" and maybe "SERVER_SSL_KEYPASSPHRASE" as the other places I would use a "secret" are already looking for a file.

Suggestions?

~tommy

[elasticmachine]

Pinging @elastic/kibana-operations

[tylersmalley]

@TJM, can you confirm if the Secure Settings keystore would work for you?

[TJM]

I am afraid the Secure Settings would have the same "issue" that environment variables have. I would need to be able to automatically run the command (cat /file/containing/setting/value | bin/kibana-keystore add the.setting.name.to.set --stdin). I do like the idea of using the keystore over environment variables, but the problem of getting the value from the "file" where DDC provides the secret value into the keystore is still there. We will be moving away from DDC (docker datacenter / docker swarm) this year, and will have a whole new way to provide secrets. We have added a helper script to cat the values into the appropriate environment variables for now.

[tylersmalley]

@jbudz or @spalger - are you aware of any precedence for this in Elasticsearch?

[spalger]

I don't think I've seen a {var}_FILE pattern before, I think a wrapper script is the right solution unless the community speaks up and expresses a wider need for this.

[TJM]

Does no one else use secrets to provide passwords? Or does no one else use Docker Datacenter swam anymore? Docker Secrets are provided as a filename, similar to mounting the secret in K8s. Perhaps, if the "password" starts with a "/" check to see if its a readable file, and if so, read its contents in and replace the variable? I just thought that using ELASTICSEARCH_PASSWORD_FILE would be more supportable?

[spalger]

Yeah, I understand the concept behind the request I just can't recall hearing the request from anyone else, or seeing a similar feature implemented in other products, and would prefer to not modify the way that configuration is loaded unless it's really necessary. It's a very core, old and important system that needs to be as easy to understand and maintain as possible.

It also sounds like you've been able to accomplish your needs with a simple helper script so it doesn't sound like you really need this implemented. Is that right?

[TJM]

I was honestly hoping that other people would jump on board (me too's). I really dislike having to modify the docker image. Lots of overhead just to get a secret into a variable :) (silly docker enterprise)

[RasmusGodske]

I agree with @TJM aswell on this as well. ElasticSearch already supports this ElasticSearch Secrets.

[byt3bl33d3r]

+1, this should be supported throughout the entire ELK stack IMHO. I really don't like the idea of passing credentials via environment variables.

[rafaelcaviquioli]

I'm also migrating all application services to use _FILE instead of env vars after a vulnerability assessment, I got surprised when I noticed Kibana doesn't have ELASTICSEARCH_PASSWORD_FILE.

So far, I could apply this change for MongoDB, Postgres, RabbitMQ, Elastichsearch successfully except for Kibana.

Elasticsearch itself contains a documentation section describing the use of ELASTIC_PASSWORD_FILE: https://www.elastic.co/guide/en/elasticsearch/reference/master/docker.html#docker-configuration-methods

References.

o https://owasp.org/www-community/vulnerabilities/Password_Plaintext_Storage o https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html (keep secrets as secrets) o https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets o https://cloudberry.engineering/article/dockerfile-security-best-practices/

[radusuciu]

Would also use this feature! I think it's worthwhile supporting even outside of the context of docker swarm/compose.

[TT-JBlock]

+1

[JF-Fentron]

+1