From 361e1c4506eba12110aa480f5ce5f778d1a836f9 Mon Sep 17 00:00:00 2001 From: milldr Date: Wed, 18 Sep 2024 17:22:58 -0400 Subject: [PATCH 1/4] Use AWS SSM Parameter Store for platform secrets placement --- ...decide-on-secrets-management-placement.mdx | 55 +++++++++++++++++++ ...rets-management-strategy-for-terraform.mdx | 11 ++-- 2 files changed, 62 insertions(+), 4 deletions(-) create mode 100644 docs/layers/project/design-decisions/decide-on-secrets-management-placement.mdx diff --git a/docs/layers/project/design-decisions/decide-on-secrets-management-placement.mdx b/docs/layers/project/design-decisions/decide-on-secrets-management-placement.mdx new file mode 100644 index 000000000..0372739ed --- /dev/null +++ b/docs/layers/project/design-decisions/decide-on-secrets-management-placement.mdx @@ -0,0 +1,55 @@ +--- +title: "Decide on Secrets Placement for Terraform" +sidebar_label: "Secrets Placement" +sidebar_position: 5 +refarch_id: REFARCH-81 +description: "Decide where to store secrets used by Terraform" +--- +import Intro from '@site/src/components/Intro'; + + +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 + +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](https://aws.amazon.com/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`. + +## Related + +- [Decide on Secrets Strategy for Terraform](/layers/project/design-decisions/decide-on-secrets-management-strategy-for-terraform/) + diff --git a/docs/layers/project/design-decisions/decide-on-secrets-management-strategy-for-terraform.mdx b/docs/layers/project/design-decisions/decide-on-secrets-management-strategy-for-terraform.mdx index a39fb5643..ab67ca68a 100644 --- a/docs/layers/project/design-decisions/decide-on-secrets-management-strategy-for-terraform.mdx +++ b/docs/layers/project/design-decisions/decide-on-secrets-management-strategy-for-terraform.mdx @@ -3,13 +3,13 @@ title: "Decide on Secrets Management Strategy for Terraform" sidebar_label: "Secrets Management" sidebar_position: 5 refarch_id: REFARCH-81 -description: "Decide where to manage secrets used by Terraform" +description: "Decide how to manage secrets used by Terraform" --- import Intro from '@site/src/components/Intro'; import KeyPoints from '@site/src/components/KeyPoints'; -Deciding where to store secrets is crucial for securing both platform integration and application data when using Terraform. The appropriate secret store depends on the stack layer and must account for situations where other infrastructure might not yet be in place (e.g. Vault, Kubernetes, etc). +Deciding how to store secrets is crucial for securing both platform integration and application data when using Terraform. The appropriate secret store depends on the stack layer and must account for situations where other infrastructure might not yet be in place (e.g. Vault, Kubernetes, etc). We need to decide where secrets will be kept. We’ll need to be able to securely store platform integration secrets (e.g. master keys for RDS, HashiCorp Vault unseal keys, etc) as well as application secrets (any secure customer data). @@ -22,8 +22,11 @@ like ASM/SSM is required. - SSM Parameter Store + KMS for all platform-level secrets used by `infrastructure` and `terraform` -- AWS Secrets Manager supports automatic key rotation which almost nothing other than RDS supports and requires - applications to be modified in order to use it to the full extent. +- AWS Secrets Manager supports automatic key rotation which almost nothing other than RDS supports and requires applications to be modified in order to use it to the full extent. + +## Decision + +We will use AWS SSM Parameter Store for all platform-level secrets used by `infrastructure` and `terraform`. ## Related From afc09fbe9d325d80c3b7e1e45ea834d435fb348f Mon Sep 17 00:00:00 2001 From: milldr Date: Wed, 18 Sep 2024 17:25:10 -0400 Subject: [PATCH 2/4] Update secrets management strategy for Terraform --- .../decide-on-secrets-management-strategy-for-terraform.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/layers/project/design-decisions/decide-on-secrets-management-strategy-for-terraform.mdx b/docs/layers/project/design-decisions/decide-on-secrets-management-strategy-for-terraform.mdx index ab67ca68a..243586540 100644 --- a/docs/layers/project/design-decisions/decide-on-secrets-management-strategy-for-terraform.mdx +++ b/docs/layers/project/design-decisions/decide-on-secrets-management-strategy-for-terraform.mdx @@ -20,13 +20,13 @@ like ASM/SSM is required. - e.g. Vault deployed as helm chart in each tenant environment using KMS keys for automatic unsealing (this chart already exists) -- SSM Parameter Store + KMS for all platform-level secrets used by `infrastructure` and `terraform` +- SSM Parameter Store + KMS for all platform-level secrets used by `infrastructure` and Terraform - AWS Secrets Manager supports automatic key rotation which almost nothing other than RDS supports and requires applications to be modified in order to use it to the full extent. ## Decision -We will use AWS SSM Parameter Store for all platform-level secrets used by `infrastructure` and `terraform`. +We will use AWS SSM Parameter Store for all platform-level secrets used by `infrastructure` and Terraform. ## Related From ff9d98384a9195279c974bdcf580f6595e77b7cc Mon Sep 17 00:00:00 2001 From: milldr Date: Wed, 18 Sep 2024 17:25:52 -0400 Subject: [PATCH 3/4] Decide on secrets management placement options --- .../design-decisions/decide-on-secrets-management-placement.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/layers/project/design-decisions/decide-on-secrets-management-placement.mdx b/docs/layers/project/design-decisions/decide-on-secrets-management-placement.mdx index 0372739ed..454e69f70 100644 --- a/docs/layers/project/design-decisions/decide-on-secrets-management-placement.mdx +++ b/docs/layers/project/design-decisions/decide-on-secrets-management-placement.mdx @@ -13,7 +13,7 @@ We need to decide where to store secrets used by Terraform. We have two options: ## Context -There are two reasonable options for storing secrets in our AWS account architecture. We need to decide which one to use. +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 From b25d8731b5657cd3dd4237b862404375dc6610e1 Mon Sep 17 00:00:00 2001 From: Dan Miller Date: Thu, 3 Oct 2024 16:41:15 -0400 Subject: [PATCH 4/4] Update docs/layers/project/design-decisions/decide-on-secrets-management-strategy-for-terraform.mdx Co-authored-by: Erik Osterman (CEO @ Cloud Posse) --- .../decide-on-secrets-management-strategy-for-terraform.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/layers/project/design-decisions/decide-on-secrets-management-strategy-for-terraform.mdx b/docs/layers/project/design-decisions/decide-on-secrets-management-strategy-for-terraform.mdx index 243586540..1d5894ca1 100644 --- a/docs/layers/project/design-decisions/decide-on-secrets-management-strategy-for-terraform.mdx +++ b/docs/layers/project/design-decisions/decide-on-secrets-management-strategy-for-terraform.mdx @@ -24,7 +24,7 @@ like ASM/SSM is required. - AWS Secrets Manager supports automatic key rotation which almost nothing other than RDS supports and requires applications to be modified in order to use it to the full extent. -## Decision +## Recommendation We will use AWS SSM Parameter Store for all platform-level secrets used by `infrastructure` and Terraform.