How do you manage SSM params that don't change with AWS accounts/envs

user_2699001 0
Viewed 57

We have separate AWS accounts for dev/stage/qa/prod envs. There are some third-party tools we use which each have their access keys. These don't change with the environment but we end up creating them in all accounts.

I feel that's redundant and should be avoided. How and where (/which account) do you manage such parameters in?

aws-ssm serverless amazon-web-services
2 Answers

It seems that you are not referring to the IAM access keys but some generic tokens required by the 3rd party tools. If you're in charge how 3rd party tools are retrieving secrets I would recommend the following approach.

  1. Store "secrets" in a centralised account lets say shared-services, ideally you would have shared-services prod and nonprod
  2. In shared-services account(s) provision a cross-account IAM role with a limited permissions to only retrieve a subset of specific SSM Parameters, configure role trust-policy on the role to be assumed only from specific accounts

So the process of of retrieving secrets by 3rd party tools would be the following

  1. assume specific cross-account role in the shared-services
  2. using cross-account role permissions retrieve required secret(s)

This is a very generic way of centralising the storage and retrieval of common secrets, it's obviously will get slightly different depending on your architecture

user_10552000

I put them in to a shared services account, and use a tool for extraction and creation of .env files for them. These services are usually not aws aware and cannot read directly from ssm, but .env files or setting the values in the shell env usually works with many tools.

To make this process easy and includable in ci cd pipelines i wrote a tool in go for that, a single binary with no dependencies for multiple plattforms:

https://github.com/gork74/aws-parameter-bulk

user_87696920
Related