Docker secrets security

[saltedcarpaccio (ArgusAgony)]

So I’ve been reading about Docker secrets because I have some credentials I need to feed to some python scripts. And I’ve set up a docker compose where I have all my credentials in .txt files that then get sent to the image as environment variables and are read by the scripts from the secrets folder and all that, it works just fine.

The thing is that if I change my script to print the variable that holds the credentials it will print it in plaintext.

So what’s stopping someone from putting a text editor on an image I upload and writing in a script to read the secrets?

What are best practices with secrets and how do I feed my python scripts the necessary information without the possibility of leaking that data?

[meyay (Metin Y.)]

@saltedcarpaccio

So what’s stopping someone from putting a text editor on an image I upload and writing in a script to read the secrets?

Can you elaborate on that? Are you seriously embedding secrets as part of source code, payload or configurations within your images and push them to a public registry?! Heck, people with the right state of mind don’t even push embedded secrets into a scm…

Or are you talking about docker secrets? Because if you do, there are contradicting statements in your post: why would a docker secret be exposed from environment variables? Why would a docker secret be part of an image you build?

I assume you are speaking about docker secrets as in “runtime configurations” without necessarily meaning docker secrets… If you do speak about docker secrets, there are some oddities I’d like to share: even though docker secrects have buildin support for different drivers, there is practicaly no publicly available secret driver. Appart from a PoC that queries life data from a Hashicorp Vault, there is no other public driver I am aware of. The buildin secret driver is able to either use a string or read a file and mount its content as file into a container. Kubernetes on the other hand has different type of secrets for different use cases - docker or better swarm has just the technical stub implemented to support diffent drivers - but due to the availability of secret drivers, it is safe to say that swarm has only one simple secret type.

Environment variables and docker secrets are not the same thing. While environments can be used to store secrets as plain text payload, a docker secret actualy is mapped as a read-only file on a volatile tempfs mount into the container. Docker secrets will not showup in the environment, unless you specifly read the files and export them as a variables. Though, whoever is able to get into the container (docker exec? or an exploited app inside the container?) can’t be stopped from accessing its content either.

Maybee you are looking for something secure like HashiCorp Vault, or something less secure like a key/value store. Both would be external systems/containers and would be quried during runtime within your application.

[saltedcarpaccio (ArgusAgony)]

Yes, it sounds like HashiCorp vault is more in line with what I am looking for. Though when people talk about using secrets for python they suggest hardcoding the secret path into the application.

I basically did what this website said with my docker-compose file.

how do you manage secret values with docker-compose v3.1?

Reading about secrets here, one of the users suggests after running the docker compose with the secrets
to " Now your app can access the secret file at /run/secrets/secrets_yaml . You can either hardcode this path in your application or create a symbolic link."
This is the part I’m having trouble with. If you hardcode the path into the application then someone else can just go access it later, since the secrets are readonly files within an image?

[meyay (Metin Y.)]

@saltedcarpaccio

Reading about secrets here, one of the users suggests after running the docker compose with the secrets
to " Now your app can access the secret file at /run/secrets/secrets_yaml . You can either hardcode this path in your application or create a symbolic link."

Actualy if the short syntax is used, it’s /run/secrets/{secret name}. If the long syntax is used, you can mount it wherever you want. Typicaly people end up configuring the path as ENV and read the file from within their application using the ENV’s value.

@saltedcarpaccio

This is the part I’m having trouble with. If you hardcode the path into the application then someone else can just go access it later, since the secrets are readonly files within an image?

the answer is already covered by my previous response:

@meyay

While environments can be used to store secrets as plain text payload, a docker secret actualy is mapped as a read-only file on a volatile tempfs mount into the container. Docker secrets will not showup in the environment, unless you specifly read the files and export them as a variables. Though, whoever is able to get into the container (docker exec? or an exploited app inside the container?) can’t be stopped from accessing its content either.