Correct usage of Chamber of Secrets

[mtb-xt]

Hi guys,

There are several ways to get secrets in my terraform code listed on cloudposse and atmos.tools.

What is the one you actually currently recommend? Given this workflow:

I created a secret in chamber, for example like this:

AWS_PROFILE=nsp-data-gbl-prod-poweruser chamber write databricks client_id -- test

and my terraform code now needs to use it, something like this:

main.tf:

# --- Initialise Databricks provider in MWS mode (for workspace provisioning) ---
provider "databricks" {
  alias      = "mws"
  host       = "https://accounts.cloud.databricks.com"
  account_id = var.databricks_account_id
  client_id = var.client_id
  client_secret = var.client_secret
}

variable "client_id" {
  type        = string
  description = "The client ID for authenticating with the Databricks API (typically from a service principal or OAuth app)."
}

variable "client_secret" {
  type        = string
  description = "The client secret associated with the Databricks client ID for API authentication."
}

How do I get them there? From atmos, using atmos.Store?
https://atmos.tools/core-concepts/share-data/#function-atmosstore

Or directly from terraform?
https://docs.cloudposse.com/modules/library/aws/ssm-parameter-chamber-reader/

What do you prefer? What (if any) is the rule of thumb?

[milldr]

You have a few choices when it comes to secrets management, and ultimately it’ll depend on your use case. We recommend using AWS SSM Parameter Store to store the secret, where you define the path to the secret as a Terraform variable.

We do not recommend storing the secret directly in Terraform. Doing so means the secret is saved to Git and to Terraform state, and may be exposed if we give another user read access to state (which is not uncommon).

We also do not recommend using !store with Atmos for secrets at this time. The store feature is not designed with sensitive values in mind — values are printed to Atmos logs, which can inadvertently expose credentials.

AWS SSM Parameter Store is the best solution because:

• It supports secure, encrypted storage via KMS.
• It allows fine-grained IAM permissions, so only the necessary roles or users can access specific secrets.
• It integrates well with Terraform

In your workflow, you’d write the secret to SSM Parameter Store (e.g., using chamber or the AWS CLI), then configure your Terraform variables to reference those paths.

Also, please see our design decision on Secrets Management Strategy for Terraform and Secrets Placement for Terraform