Like you’re using the AWS cli! It’s one call to https://docs.aws.amazon.com/cli/latest/reference/ssm/get-par... away.
It even has built in Ansible support https://docs.ansible.com/ansible/latest/collections/amazon/a... and can values can be rendered in Cloudformation templates natively.
Too hard? Maybe try Chamber https://github.com/segmentio/chamber It has support for multiple backends and can render secrets in lots of different formats.
Would be keen to hear what other differences Leapp developers would name in comparison to Chamber. Thanks!
Chamber is an open source wrapper for AWS Parameter Store. You add a secret by doing:
`chamber write ENV_NAME SECRET_NAME SECRET_VALUE`
And when you want to execute a command with those values in your environment...
`chamber exec ENV_NAME -- yarn start:prod`
Parameter Store comes with auditing tools and versioning. Chamber uses KMS for encryption. Also, you can control permissions (including namespacing) with IAM.
My question is - what does Doppler provide that would make me want to switch? I'm weary about letting someone else own our secrets.
We started by using https://github.com/segmentio/chamber/, but because of the way we decided to structure our secrets we decided to write a clone of it ourselves (https://github.com/micvbang/confman-go).
In practice, we have a client written in Python that grabs configuration from Parameter Store and puts it into the process' ENV variables at startup. This allows us to avoid vendor lockin in the rest of our code, since we still just fetch all config from the environment. I like it so far :)
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.
I've found it pretty easy to set up, use, and not think about it. It's great for integrating with AWS IAM and whatnot.
[1]: https://github.com/segmentio/chamber
[2]: https://aws.amazon.com/blogs/mt/the-right-way-to-store-secre...