The application I'm working on has more than a dozen of secrets, SSL certificates and API keys. Currently I have a file that's added into .gitignore and it contains all my secrets. How to securely store all these secrets? How enterprise apps handle this, where security is top priority?

I'm looking into AWS KMS and as far as I understand I have to encrypt all of the secrets, commit it, and then at runtime pass my AWS credentials for decrypting the secrets (user is only allowed to use KMS key for decrypting and no other permissions are added for the user).

Now, assuming the machine where containers are run is compromised - secrets are encrypted, so that should be fine, but! if docker inspect command is run, it will display all environment variables (the AWS secrets), so I exec into the container and all I have to do is to use the env variables to decrypt the secrets.. sort of defeats the purpose or maybe I am missing a step somewhere?

Note: My current solution is not secure too - file is gitignored, but it still exists on the machine where the containers are run (and later, after image is built, they are exposed as env variables).

Note 2: Git repo is private

3 Answers 3


Generally speaking you have to assume tighter security for the instance that's running the container than the container itself because, as you point out, a compromise there affects everything downstream. This is the same with the VM host that's running your ec2 instance.

A standard solution is to pass secrets into the container via environment variable. I've also seen solutions (for secrets stored in Hashicorp Vault) that create a fuse filesystem that's mounted into the container or a similar approach using a Docker volume driver. This isn't quite as straightforward, but may be easier if you're passing lots of secrets.


Docker Secrets is the new recommended method for sharing & storing secrets inside containers. Docker deliberately opted to store secrets in files under /run/secrets over the environment variable approach.

  • 2
    Docker Secrets, as of the time of my typing this, still only works with Swarm, i.e. "docker service..." and not "docker run...".
    – user102618
    Dec 21, 2017 at 21:54
  • @Marakai but can't we run a Swarm of just one?
    – jayarjo
    Sep 8, 2018 at 6:27
  • Also I wondered what was the reason to not use env vars, turns out: ...environment variables can unintentionally be leaked between containers (for instance, if you use --link).
    – jayarjo
    Sep 8, 2018 at 6:43
  • 1
    @jayarjo Now, over a year later from my original reply I would actually recommend to use something similar to the AWS parameter store and make an API call from within the container. This, if you use ECS or Docker in AWS. Azure or GCP would have their own comparable mechanisms. Maybe I should edit the question. I'm still testing this myself.
    – user102618
    Sep 9, 2018 at 0:11
  • 1
    But how safe would be to request sensitive info over API, wouldn't it require storing service specific credentials inside the Docker image again? Wouldn't it ruin the whole idea of storing them outside in first place?
    – jayarjo
    Sep 9, 2018 at 9:48

I think the best approach is to seal the secret in a JWE and keep it sealed all the time, even inside the containers. After all, a container can be, as pointed out @roman, compromised. To use the secret, a simple tool is used to unseal the secret and deliver it to the end-application, within the container.

  • Welcome to the community. Please elaborate how the JWE would get transmitted and exchanged and authenticated, authorized etc. Mar 8 at 22:20
  • JWE are just text file. How they appear in the container is entirely up to the designer. (S3 bucket, a vault, preloaded in the image, are all good solutions). As for using the JWE and extract the secrets, tools like tang and clevis do exactly that. All you really need to do, as NBDE does, is control access to tang.
    – Claude
    Mar 9 at 17:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .