Similar to laurentl we use AWS SSM parameter store in combination with Chamber[1] to injects our secrets as environment variables to our application code. For

Similar to laurentl we use AWS SSM parameter store in combination with Chamber[1] to injects our secrets as environment variables to our application code. For services running on ECS, each task definition has an IAM Role attached that has permissions to use secrets stored in parameter store with a prefix unique for that service (each service encrypts its secrets with its own KMS key). For example, serviceA will use the prefix serviceA and have a secret under serviceA/DB_PASSWORD and serviceB will have its own secret under serviceB/DB_PASSWORD. Each service cannot access each others secrets and even if they could, they also need access to use the corresponding KMS key before they're able to read the secrets. Since secrets are added as environment variables we can inject them during startup with chamber. The entry point for your docker container might look as following `CMD ["chamber", "exec", "serviceA", "--", "./executable"]`. Chamber will inject the secrets store in SSM before starting the executable which reads the secrets from the env variables. For other services such as Lambda we do not use environment variables, instead we use the AWS SDK to fetch secrets during cold starts and cache them for the duration of the Lambda container. If you're using Node.js lambda functions this is a little bit trickier to do than Go or python lambdas but it's still possible. The Lambda function also has an IAM access to only fetch the secrets under its own prefix. For adding, removing or editing secrets we can use the chamber CLI with each individual devs AWS access keys. For example: `chamber write serviceA PASSWORD hunter2` to write a new secret or `chamber list serviceA` to list set secrets. [1] https://github.com/segmentio/chamber https://github.com/segmentio/chamber