Ephemeral resources fetch secrets during execution and avoid persisting them to state, while data sources still store the returned values in state. The practical difference is recoverability: anything in state can be exposed later to anyone who can read it. Use ephemeral resources for sensitive credentials and data sources only for low-risk values.
How ephemeral resources and data sources differ in secret handling
Ephemeral resources are designed to retrieve secrets at runtime and then disappear without leaving the secret behind in persistent state. Data sources are read during execution too, but their returned values are still written into state, which means the secret can live beyond the run and be exposed later if that state is readable.
The difference is not about whether a secret is fetched, but where it ends up after fetch. If a workflow or module writes the secret into state, you have created a durable copy of sensitive material. If it is only present in transient memory or runtime execution, the exposure window is much smaller and easier to control.
That matters because state is often broader in reach than people expect. It may be stored in remote backends, copied into CI logs, shared with collaborators, or retained for troubleshooting. For sensitive credentials, the design goal is to keep the secret out of any artifact that survives the run.
Why state persistence changes the security profile
Once a secret is in state, access to that state becomes access to the secret. Even when the original secret was fetched securely, the persisted copy can bypass the protections you thought you had around the secret store itself. That creates a second trust boundary around the infrastructure that stores and distributes state.
This is why the choice between ephemeral resources and data sources is really a choice between transient retrieval and durable disclosure. Data sources can be acceptable for low-risk values such as non-sensitive lookups, identifiers, or configuration that would not materially harm you if exposed. For anything that authenticates to another system, the persistence risk usually outweighs the convenience.
Operationally, the issue is recoverability. If someone can read state later, they may recover credentials long after the original execution ended. That can turn a one-time provisioning action into a lasting exposure path, especially when state is backed up, replicated, or shared across teams.
When to choose one pattern over the other
Use ephemeral resources when the returned value is sensitive, short-lived by design, or intended only for immediate use inside the run. Use data sources only when the returned value is low impact if exposed and you want the convenience of referencing it again without re-fetching it.
A practical rule is to ask whether the value would be safe if copied into a long-lived artifact. If the answer is no, treat persistence as a defect, not a convenience. If the answer is yes, a data source may be acceptable, but you should still confirm that the state backend and access model match the sensitivity of the value.
At scale, this distinction becomes a governance issue as much as a technical one. Teams often start with harmless lookups and gradually reuse the same pattern for secrets, tokens, or API keys. That drift is what turns a simple configuration choice into a recurring exposure mechanism.
Risk and Threat Considerations
Persisting secret values in state expands the blast radius of a compromise. Anyone who can read the state, whether through misconfiguration, overbroad access, logging, backups, or a downstream breach, may gain the same credential material that the original runtime retrieved.
Failure mechanism: A data source stores its returned secret in state, and that state is later exposed through access sprawl, replication, or inspection of supporting infrastructure.
Impact: The secret can be reused to impersonate the original principal, access downstream systems, or enable lateral movement until the credential is rotated or revoked.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, OWASP ASVS and NIST Zero Trust (SP 800-207) set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | State persistence can leak secrets returned by lookup mechanisms. |
| NHI-07 — Long-Lived Secrets | Data sources can unintentionally turn transient secrets into long-lived stored values. | |
| Recommendation — Keep sensitive runtime secrets out of durable state and rotate any exposed credentials. Prefer short-lived secrets and avoid patterns that persist credentials beyond execution. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The question concerns handling and lifecycle of secret material used for authentication. |
| AC-6 — Least Privilege | State access determines who can recover stored secret values. | |
| Recommendation — Manage authenticator lifecycle so credentials are not stored or retained longer than needed. Restrict state access to the minimum set of operators and systems. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Secret persistence raises the need to protect sensitive values at rest and in transit. |
| Recommendation — Protect stored sensitive values with strong encryption and controlled key access. | ||
| OWASP ASVS | V14 — Data Protection | Persisted secrets in state are a data protection concern. |
| Recommendation — Ensure sensitive values are never exposed through logs, storage, or cached application artifacts. | ||
| NIST Zero Trust (SP 800-207) | AC-6 — Least Privilege Access | Access to state becomes a trust boundary that should be tightly constrained. |
| Recommendation — Limit read access to state so only explicitly authorized operators can retrieve it. | ||
Practitioner Guidance
What to verify: Confirm whether the value returned by the secret lookup is written to local or remote state, and inspect the access paths to every place that state is stored, backed up, or exported.
Decision rule: If the value can authenticate to a real system, assume it is sensitive enough to avoid state persistence unless there is a strong and documented exception.
Common mistake: Treating “fetched during apply” as inherently safe. Runtime retrieval reduces exposure only if the value is not committed to a durable artifact afterward.
Practitioner takeaway: The safe pattern is the one that prevents secret recovery after the run ends, not the one that merely hides the lookup during execution.
Related resources from NHI Mgmt Group
- What is the difference between secrets rotation and secretless authentication for AWS workloads?
- What is the difference between restoring Snowflake data and restoring Snowflake configuration?
- What is the difference between data recovery and network control plane recovery?
- What is the difference between importing RDS resources and rebuilding them?