Best practices for managing secrets and configurations in ECS containers:

Requirements:

  • configurations and secrets stored in paramter store and/or S3 bucket;
  • encrypt secrets;
  • do not push configurations to git/version control system;
  • transparent to apps (e.g. it should be completely transparent for backend; it should not have code for pulling configurations/secrets from anywhere) this follows the 12 factor app style (https://12factor.net/);
  • automatic reloads new configurations when these change upstream;

envaws created by me and presented at the Nordics AWS conf. IMO, the best way to approach the problem: it completely makes the handling of configurations and secrets transparent to the application. In the Dockerfile, by running: CMD envaws yarn start, the envaws will fetch the configurations from AWS parameterstore and/or S3 and populate the given command process with the configurations as env variables. As a bonus, we get also a polling mechanism out of the box: if the configurations change upstream, the docker container is rebooted and fetches the new configurations.

chamber similar to envaws, but without the poller (so it does not automatically reload if configurations change); Needs more configuration; It is an overkill if we consider the requirements above, since it has a lot more functionality.

fetch configurations at start in container: this option is not compliant with the ‘transparent for application’ requirement. in this case, the ECS task would have to run aws commands to fetch the configurations from AWS parameter store.