It seems that the correct approach to supplying secrets to Docker containers is debatable. This question is the closest to mine, to which one person answered that environment variables are ok, but a comment quoted Docker as saying the opposite.

We don't have access to the 'secrets' functionality of Docker, either, as far as I know.

We are using Amazon Web Services (AWS) Elastic Container Service (ECS) with the Fargate launch type, which automates scaling for us. We are storing secrets in the Parameter Store, inside Amazon's Systems Manager utility.

There are two options proposed:

  • Pull down the unencrypted* secrets as part of starting the process. These values would then be placed on the environment variables file (.env) and imported into the process when it is started.
  • Start the process, and load the secrets within it. This will be done either directly from the AWS SDK or via another of our authenticated services.

The second option ensures that the secrets stay within the process's memory, preventing the use of the inspect flag on a Docker console. However, in either case, I'm not familiar enough with the actual setup of ECS to know what security vulnerabilities may exist if it is done this way. I want to ensure the safety of my secrets.

In either case, this would currently run once, at process start. The second option would be nice for triggering refreshes, but that's a different discussion.

* I know that I could pull down the encrypted values in the first option, then have the process use the AWS SDK to decrypt them, but at that point it seems less work (cpu + network) to do option 2, with all the values returned decrypted.

1 Answer 1


Generally the best approach to secrets management in containerized environments is to make use of some form of secrets management software. In essence most of these solutions comprise an encrypted database and a mechanism for containers to be provided with specific secrets at run time based on a provided identity.

In Docker this can be leveraged in swarm mode using the docker secret command. Another alternative to this would be to use Hashicorp Vault or one of the other secrets management tools that are available.

Also within an AWS environment it's possible to use something like their CloudHSM feature from within Docker containers (more information here)

You must log in to answer this question.

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