liveBook · Manning

Secret management

As explained in Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu

A secret manager is software that securely stores, controls access to, and retrieves sensitive values such as credentials and API keys.

An API key may be needed for deployment even when the service cannot use OIDC. A secret manager stores the key centrally instead of leaving its value in a Terraform variable or project configuration. Think of it as a password manager for automated processes: a secret has an identifier or path, and access can be controlled by role. section 8.5.2

Choose how the workload will receive the value:

  • Prefer passing the secret’s path to a container orchestrator when it can retrieve the value directly. Terraform then need not handle the secret value. section 5.4.6 section 8.5.2
  • If Terraform needs the value, pass in the identifier and retrieve it with a data source. Marking an output sensitive does not guarantee the retrieved value is absent from state. section 8.5.2
Listing 8.16 Examples of different secret managers
#
# AWS
#
 
data "aws_secretsmanager_secret" "example" {                       #1
  arn = var.secret_arn
}
 
data "aws_secretsmanager_secret_version" "secret-version" {        #2
  secret_id = data.aws_secretsmanager_secret.example.id
}
 
output "aws_secret_value" {
  value     = data.aws_secretsmanager_secret-version.value         #3
  sensitive = true                                                 #4
}
 
#
# Vault
#
 
data "vault_generic_secret" "example" {                             #5
  path = var.vault_path
}
 
output "vault_secret" {
  value     = data.vault_generic_secret.example.data[var.vault_key] #6
  sensitive = true
}
 
#
# Azure
#
 
data "azurerm_key_vault" "example" {                                #7
  name                = var.azure_vault_id
  resource_group_name = var.azure_resource_group
}
 
data "azurerm_key_vault_secret" "example" {                         #8
  name         = var.azure_secret_name
  key_vault_id = data.azurerm_key_vault.example.id
}
 
output "secret_value" {
  value     = data.azurerm_key_vault_secret.example.value           #9
  sensitive = true
}

The Terraform examples look up secrets through AWS Secrets Manager, HashiCorp Vault, and Azure Key Vault data sources. The configuration takes an identifier or path rather than placing the secret value in an input. section 8.5.2

Use OIDC where available so accessing the secret manager does not require storing another credential. Protect Terraform state regardless: a data-source lookup may put sensitive values there, and state also reveals infrastructure details. If a CD platform must store secrets itself, updating one key across many projects can become cumbersome; central management helps, but the platform will still have access to secrets it uses. section 8.5.2 section 6.2.2 section 8.5.3

How Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu covers it

How deep it goes
Explains identifier-based retrieval and compares Terraform data sources with direct workload retrieval, including the risk of secrets entering state.
Examples
Shows AWS, Vault, and Azure Terraform lookups and considers updating an API key across hundreds of projects.
What it assumes
Defines secret managers from the password-manager analogy while using Terraform variables, data sources, and state in the operational examples.
What you can do after
Apply it via Terraform data sources or configure an orchestrator to retrieve secrets without passing their values through Terraform.
How it connects
Connects secret managers to OIDC, role-based access control, Terraform data sources, state security, and container orchestration.

Also explained in

Compare how 6 books explain secret management →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Terraform in Depth: Infrastructure as Code with Terraform and OpenTofu. The section links point to the parts of the book it draws on.