Skip to main content

Decide on Secrets Placement for Terraform

We need to decide where to store secrets used by Terraform. We have two options: store secrets in each account or store them in a centralized account.

Context

Often we need to integrate with third-party services or internal services that require API keys or other secrets. We need to decide where to store these secrets so that Terraform can access them. There are two reasonable options for storing secrets in our AWS account architecture. We need to decide which one to use.

Option 1: Store Secrets in each account

The first option is to store the credential in the same account as the resource. For example, API keys scoped to dev would live in plat-dev.

Pros

  • Accounts can easily access their given credentials
  • IAM level boundaries are enforced between accounts

Cons

  • Secret administrators need to access many accounts to create those secrets
  • There is no centralized management for all secrets out there

Option 2: Store Credentials in a Centralized Account

The second option is to store the credentials in a centralized account, such as corp or auto. Now you would need to share those credentials with each account, for example with AWS RAM.

Pros

  • Centralized secrets management
  • Secret administrators have a single place to manage secrets
  • Once shared, resources in a given account still access their given secrets from their own account. They do not need to reach out to another account

Cons

  • Complexity with AWS RAM
  • Secret administrators must be careful to share secrets with the correct accounts
  • You need to decide what account to use as the centralized management account. We could deploy corp if you'd like for this or reuse auto.

Decision

We will use AWS SSM Parameter Store for all platform-level secrets used by infrastructure and terraform.