Keep API Secrets Out of Infrastructure-as-Code State

Infrastructure as Code makes resource changes reviewable and repeatable. It can also copy a credential into more durable places than the engineer who wrote the configuration intended.

HashiCorp's sensitive-data guidance draws a crucial distinction: marking a Terraform value sensitive redacts it from normal CLI and UI output, but the value can still be stored in plan and state files. HashiCorp recommends treating state as sensitive, using remote storage, encryption at rest, access controls, and audit logs. Where the language and provider support them, ephemeral values and write-only arguments can omit values from state and plans entirely.

Repository controls address another part of the path. GitHub's push protection documentation describes blocking supported hardcoded credentials before they reach a repository. That is useful prevention, but a credential injected correctly by CI can still be persisted by the Infrastructure-as-Code engine if the resource schema records it.

Trace every representation of the value

For each API credential used during provisioning, review all of the places it can appear:

• source files and variable defaults;
• developer .tfvars files and shell history;
• CI variables, step output, debug traces, and cached workspaces;
• generated plan artifacts;
• local or remote state and state backups;
• resource attributes returned by a provider; and
• downstream environment variables, configuration stores, or deployment manifests.

The important question is not only “is the input marked sensitive?” It is “does any step serialize the value, who can read that serialization, and how is it retired?”

Prefer references over copied secret values

Where possible, let Infrastructure as Code provision the secret container, access policy, or external-secret reference without reading the secret value itself. Give the runtime workload permission to retrieve the value through its identity. This separates infrastructure review from credential disclosure and reduces the number of systems that must protect the plaintext.

When Terraform must handle a secret, use supported ephemeral or write-only mechanisms where appropriate. Secure remote state with narrowly scoped access, encryption, locking, version-retention rules, and access logging. Treat plan files as sensitive artifacts too. Disable verbose debugging in shared CI unless it is required and reviewed.

Design rotation before the first apply

A safe rotation process needs overlap, consumer rollout, verification, revocation, and a way to identify stale copies. If a provider credential is copied into several resource arguments or state workspaces, rotation is an inventory exercise. Prefer one authoritative encrypted value and references that can be updated without rewriting unrelated infrastructure.

For supported AI APIs, Till can keep encrypted provider connections in its tenant store while applications receive separate scoped Till tokens. Rotating a provider connection does not require reissuing automatic scoped tokens. Those tokens are still secrets, and Till does not replace a general-purpose vault, CI secret store, or Terraform backend. The hosted beta also depends on a single regional service.

Infrastructure as Code should describe access relationships without becoming an accidental archive of every credential those relationships use. Verify that property in the state schema, not only in the terminal output.

← Back to blog