5

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

2

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.

3

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...". – Marakai Dec 21 '17 at 21:54
  • @Marakai but can't we run a Swarm of just one? – jayarjo Sep 8 '18 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 '18 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. – Marakai Sep 9 '18 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 '18 at 9:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.