An IaC tool creates a database with a generated password. Why does that plaintext password end up in the tool's recorded state, and what follows for how you store and access that record?

## Why the secret is in there at all The record's job is to remember what the tool built, which means storing the attributes of each object: the ones you supplied and the ones the provider returned. The tool has no way to distinguish a dangerous field from a boring one — both are just strings coming back from an API call. So when a resource generates a password, an initial credential, a private key, a bootstrap token or a connection string, that value is recorded like any other attribute, in the clear, inside the record. Secrets arrive by three routes: - **Generated by the provider.** An initial database password or an access key returned on creation. You often *need* it recorded, because it is the only copy. - **Supplied as input.** A password passed into a resource is part of that resource's recorded configuration. Passing it through a variable rather than a literal changes where it comes from, not where it ends up. - **Read by a lookup.** Fetching a value from a secret manager so the configuration can use it copies that value into the record too. Reading a secret with the tool is not a way to avoid recording it — it is a way to add another copy. ## Redaction is a display control The single most common misconception is that marking a value sensitive protects it at rest. In the mainstream tools it does not. Marking suppresses the value in plan output, in logs and in printed outputs — genuinely valuable, because CI logs are widely readable — but the record still stores the plaintext. Two consequences follow. Sensitive marking is a defence against *shoulder-surfing the pipeline*, not against someone who can read the record. And the absence of a mark does not mean a value is safe; nothing scans your record for secrets you never declared. ## What follows operationally The record's data classification is the maximum classification of anything inside it. Practically that means: **Encrypt it at rest and in transit.** Whatever holds it should be encrypted with a key you control, and reachable only over TLS. **Restrict read access to the identities that run the tool.** Not "the platform team", not "everyone with cloud read-only" — read on the record is equivalent to read on every secret it contains. This is the single control most often botched, because the storage is usually a general-purpose bucket or database that many roles can list. **Log access.** You want to be able to answer "who read this, and when" during an incident. Object-level audit logging on the storage is the cheap version. **Never commit it to version control**, and never attach it to a build artefact or a support bundle. It is the classic accidental disclosure: someone debugging a failure uploads the record to a ticket. **Watch the derivatives.** Saved plan files, backups and version history of the record carry the same values. Turning on versioning for recoverability means old secrets persist even after rotation, and a retention policy has to account for that. ## Reducing what lands there You cannot eliminate secrets from a record, but you can shrink the surface: - **Pass references, not values.** Where a service can resolve a secret at runtime, give it the identifier of the secret and let it fetch the value itself. The record then holds a pointer, and the value never enters it. - **Let the resource generate the credential and read it out of band.** Some resources write their generated credential directly to a secret manager, so the workload consumes it from there rather than from a tool output. - **Rotate immediately after creation.** If a value must be recorded to bootstrap, treat the recorded copy as expired: rotate the credential after provisioning, so what is in the record is no longer valid. - **Split what is truly sensitive out of the configuration entirely.** If a resource type forces a plaintext credential through the tool, that is an argument for provisioning it by another route. ## If a record leaks Treat it as a credential compromise, not a code leak. Enumerate every sensitive attribute the record contained — including in its version history — rotate each one, and check access logs for who could have read it. "It was only in a private bucket" is not a rotation policy; the point of enumerating is that most teams are surprised by what is in there. ## Stateless tools A tool that records nothing between runs has no such artefact, which is a genuine security advantage. Its secrets problem moves elsewhere: how the credential reaches the run in the first place, and whether it is echoed into logs. Different artefact, same discipline.