Terraform / Sensitive data, governance, and recovery / Lesson 13
Sensitive, ephemeral, and write-only boundaries
Protect secret flows across inputs, plans, state, providers, outputs, and logs without mistaking redaction for erasure.
On this page
Lesson goals
- Distinguish sensitive presentation from persistence and access control.
- Explain versioned ephemeral and provider-specific write-only constraints.
Classify every place a value can travel
A credential can enter through an input channel, be passed to a provider, appear in a diagnostic, and become part of a persisted attribute or artifact. Marking a value sensitive affects supported presentation and propagation but is not encryption or a general guarantee of nonpersistence. State, saved plans, JSON exports, logs, caches, and access-controlled storage need separate review. Use synthetic noncredentials in tests and documentation, and never publish an actual token merely because a normal terminal summary happened to hide it.
Declare an ephemeral input without embedding a secret
Terraform 1.16 supports ephemeral variables, a feature introduced earlier in the 1.x line. The complete contract below has no default credential and no resource consumer. An ephemeral value is omitted from state and plan persistence under its supported language rules, but references are restricted to permitted ephemeral contexts. It cannot simply be assigned to an ordinary persisted resource argument or exported as an ephemeral root output. Provider authentication, supported child-module flows, and provider-defined write-only arguments require their own compatible configurations.
terraform {
required_version = ">= 1.16.0, < 1.17.0"
}
variable "session_token" {
type = string
nullable = false
sensitive = true
ephemeral = true
}
No real value is provided. sensitive controls presentation while ephemeral changes supported persistence behavior and legal reference contexts. The declaration alone does not configure a provider, encrypt a backend, rotate a credential, or prevent an external system from logging what it receives.
Provider support defines write-only resource behavior
Write-only resource arguments are available only where the provider and resource schema implement them, with a compatible Terraform version. They can accept values that should not be retained as ordinary managed attributes, but update and rotation behavior remains resource-specific. A companion revision argument may be needed because an omitted secret cannot be compared later like a normal stored value. Do not assume that renaming an argument or adding sensitive=true creates write-only behavior. Review the exact schema and its change-detection contract.
Hidden display can coexist with a retained underlying value
The offline demonstration makes a redacted display copy of a synthetic record while retaining the original in memory. It is not a Terraform state representation or a claim that every redacted variable follows this exact path. The point is the distinction between presentation and underlying information. A logging or export consumer that receives the original record can still reveal it. Design access and retention around actual data flows, and minimize which values are published or stored rather than relying solely on interface cosmetics.
record = {'service': 'atlas-api', 'value': 'training-only'}
display = dict(record)
display['value'] = '<redacted>'
print('display=' + display['value'])
print(f'underlying_value_present={record["value"] == "training-only"}')
display=<redacted>
underlying_value_present=True
The display hides a harmless teaching value while the original remains present. No files, state, plans, providers, or credentials are read. The example proves only that making a display copy is different from removing underlying information.
Rotation and incident handling cross several boundaries
A secure workflow uses approved secret delivery, short-lived identity where appropriate, narrowly scoped permissions, protected state and artifacts, and redacted diagnostics. Rotation must account for provider sessions, stored consumers, application reload, and recovery rather than merely changing an input string. If exposure occurs, preserve the necessary incident evidence while revoking or rotating through the authorized process. Deleting a local file does not prove every remote artifact, backup, or log copy disappeared. This course handles only synthetic values and never retrieves, transmits, or rotates real credentials.
Common errors and fixes
Sensitive is treated as never stored.
- Why it happens
- Console redaction was confused with persistence and access restrictions.
- How to fix it
- Trace actual value storage and protect every sensitive artifact.
- Prevent it next time
- Review confidentiality independently from ordinary output appearance.
An ephemeral value is assigned to a persisted argument.
- Why it happens
- The consumer is outside permitted ephemeral contexts.
- How to fix it
- Use a supported provider/authentication or write-only contract without forcing persistence.
- Prevent it next time
- Verify Terraform and provider feature support separately.
Rotation appears complete but an old consumer still uses the credential.
- Why it happens
- Input change was mistaken for full session and downstream adoption.
- How to fix it
- Verify each intended consumer and the approved revocation/reload process.
- Prevent it next time
- Document rotation ownership and recovery evidence across systems.
Check your understanding
1. Does the temporary variable declaration guarantee that a provider cannot log its value?
Show worked solution
No. It constrains supported Terraform persistence and usage, while provider behavior and external systems are additional boundaries. Review their contracts and diagnostic practices separately. Avoid real secrets in examples and minimize exposure even when ephemeral and sensitive controls are correctly declared.
2. Why may write-only secret rotation need a separate revision input?
Show worked solution
When Terraform does not retain the secret value, ordinary stored-value comparison cannot detect every intended rotation. A provider may define a separate version or trigger argument to express that intent. Follow the exact resource contract instead of assuming every secret change produces a detectable plan difference.
Key takeaways
- Redaction, nonpersistence, encryption, and authorization protect different boundaries.
- Use only supported ephemeral and write-only flows with reviewed consumers.