Hello,
We got to know that, from v1.6.0 onwards, compose file support for rancher secret is enabled. But we are unable to do with below configuration in docker-compose.yml of the catalog. Its giving "Error (Service ‘mariadb’ configuration key ‘environment’ contains an invalid type, it should be an array or object) "
environment:
- MYSQL_ROOT_PASSWORD_FILE=/run/secrets/dbpass
volumes:
mariadb:
driver: secrets-driver
Is there anything missing?
You need to add this section:
`
secrets:
You don’t need secrets-driver.
Thanks for the reply, but it appears to be docker secrets, not the rancher secrets.
From the release notes on rancher 1.6, it appears that secret parameter supports docker-compose.yml in UI. It uses secret-driver. I can now even deploy with environment variable named MYSQL_ROOT_PASSWORD_FILE, but the value defined in /run/secrets/dbpass is not populating into variable MYSQL_ROOT_PASSWORD. But it simply map the path name /run/secrets/dbpass to entire variable name MYSQL_ROOT_PASSWORD_FILE
So I suspect we have to define environment variable in a different way(than _FILE)
Any idea?
Secrets does not populate an environment variable with the password. The entire point of it is to provide an alternative to that, because environment variables have a variety of problems. They populate a file (through the secrets volume driver) which can be read in the container.
The pseudo-standard supported by official images like MySQL is to read a path from an environment variable (..._FILE) and get the password from the contents of that file.
@vincent in the docs there is (https://docs.rancher.com/rancher/v1.6/en/cattle/secrets/):
To take advantage of this, append _FILE to the environment variable name and the value would be /run/secrets/NAME>. When the container starts up, the value in the file will be assigned to the environment variable.
I was under the impression that the environment variable will be populated with value from file after reading this.
I couldn’t get it to work.
So the reality is that the images have unofficial convention of reading values from files if the env-var name ends with _FILE? and there is not way to put value from /run/secrets/x to environment variable automatically? Is that correct?
That is what actually happens, but it is implemented by the image/entrypoint itself, not functionality built-in to Docker/Rancher. It’s just the pattern the common library images implement.
To take advantage of this, append _FILE to the environment variable name and the value would be /run/secrets/NAME>. When the container starts up, the value in the file will be assigned to the environment variable.
I had high hopes too, when I read this part. But quick googling revealed that you need image that implements this. Kinda disappointed.
I’d love to see native support for secrets as environment variables in Rancher. Is there any chance? Would creating GitHub issue help to bring more attention to this feature?
No; environment variables are less secure and we (and Docker secrets) intentionally do not support that.
okay. But is it possible to atleast hide(encrypt) the values corresponding environment variables in “View config” section of a stack created?(just like hiding in UI while using “password” type option of a variable). Guess it will improve the security more
The environment of a process is not secret. And that doesn’t accomplish anything anyway, the same string has to work if reimported and you can just print it out there.
If you want security, use secrets and read them from the (in-memory filesystem) file into your process memory. There is really not a lot in between.
(For bonus points, run the app as a non-root user and chmod the secrets so they’re no longer readable from the container after you load the values.)