Pulumi secrets management shows why stack-level controls fall short

At a glance

What this is: This is an analysis of Pulumi secrets management and the limits of stack-level secrets handling across IaC, pipelines, and runtime access.

Why it matters: It matters because IAM, PAM, and NHI teams need secrets controls that span stacks, not just encrypted state, if they want least privilege, rotation, and auditability to hold up in production.

By the numbers:

• 27 days
• Only 44% of organisations are currently using a dedicated secrets management system.

👉 Read Infisical’s full analysis of Pulumi secrets management across stacks and pipelines

Context

Pulumi gives infrastructure teams programmable control over cloud resources, but its secrets model still has to deal with credentials, tokens, certificates, and state data that move through stacks and pipelines. In practice, that makes secrets governance part of the infrastructure control plane, not a side concern.

The core problem is not encryption alone. It is whether access can be scoped, rotated, and audited across deployment systems, build systems, and runtime environments without creating separate exceptions for each one. That is where NHI governance becomes the deciding discipline for Pulumi users.

Key questions

Q: How should security teams govern secrets used across Pulumi stacks and pipelines?

A: Govern them as a shared identity problem, not as a stack feature. Assign each secret an owner, define who may request it, set a lifecycle for rotation and revocation, and centralise audit logging across IaC, CI/CD, and runtime consumers. That prevents Pulumi from becoming the only policy boundary.

Q: Why do stack-level secrets controls fail at production scale?

A: Stack-level controls fail because they protect where a secret is stored, but not how widely it can be reused or how long it stays valid. Once the same credential is consumed by pipelines, workloads, and operators, the blast radius becomes larger than the stack boundary.

Q: What do teams get wrong about encrypted secrets in infrastructure code?

A: They confuse encryption with governance. Encrypting a secret in state is useful, but it does not provide per-secret access control, temporary access, or lifecycle enforcement. Teams still need policy, rotation, and audit controls outside the IaC tool.

Q: How do you know if your secrets management model is actually working?

A: You should be able to answer who accessed each secret, through which system, for what purpose, and whether access expired as intended. If you cannot produce that trace across stacks and pipelines, the model is incomplete even if encryption is in place.

Technical breakdown

How Pulumi stack secrets are stored and propagated

Pulumi marks values as secret at the stack level, encrypts them before writing state, and propagates the secret flag through derived outputs. That protects values from casual exposure in state files and CLI output, but it does not change the underlying governance model. Access is still governed largely by stack access and whatever backend encryption provider is in use. In other words, Pulumi secures storage, not policy granularity. Practical implication: treat Pulumi encryption as a storage control, not a full secrets governance system.

Practical implication: separate encrypted state from secrets policy, and do not assume state encryption gives per-secret governance.

Why static secrets and manual rotation create operational risk

Pulumi’s native model stores secrets as static values unless teams add an external service. Static credentials do not expire on their own, and manual rotation depends on someone updating config, rerunning deployments, and verifying every downstream consumer picked up the change. That is acceptable for small environments, but it becomes fragile when the same credential is used across stacks, pipelines, and applications. The control problem is not just exposure. It is the long-lived blast radius of a credential that stays valid after the original need has passed. Practical implication: use short-lived credentials where production scope justifies it.

Practical implication: replace long-lived static secrets with time-bound credentials wherever deployment paths and runtime consumers make that possible.

How external secrets managers change the control plane

An external secrets manager shifts authority out of the IaC tool and into a dedicated policy layer. In this pattern, Pulumi orchestrates infrastructure, while the secrets system decides who can read a secret, when access expires, whether a credential is generated on demand, and how access is logged across tools. That separation matters because IaC stacks, Kubernetes workloads, and CI/CD jobs all consume secrets differently. Centralising access control, dynamic secret issuance, and audit logging gives organisations one place to govern identity-bearing secrets across the whole delivery chain. Practical implication: use Pulumi to provision, but use a separate secrets authority to govern lifecycle and access.

Practical implication: build a central policy layer for secrets if the same credentials touch IaC, CI/CD, and runtime systems.

NHI Mgmt Group analysis

Stack-level encryption is not secrets governance. Pulumi can encrypt values in state, but that does not provide the per-secret policy, time-bounded access, or cross-system auditability that production environments need. The governance failure is treating storage protection as if it were access governance. Practitioners should stop assuming that encrypted state closes the control gap.

Static secrets create durable blast radius in infrastructure delivery. When credentials stay valid across stacks, pipelines, and runtimes, the exposure window outlives the deployment that created it. That is a control problem for NHI programmes because the credential remains usable long after the original operational need has changed. The implication is that rotation alone is not enough unless the architecture also reduces standing validity.

Granular secret policy is now part of infrastructure design, not a later hardening step. Pulumi’s all-or-nothing stack access model shows why least privilege must be enforced at the secret object, environment, and workflow level. Ephemeral credential trust debt: production teams accumulate risk when they rely on long-lived credentials to support fast-moving infrastructure delivery. Practitioners should design secrets governance alongside IaC, not after it.

The right boundary is between orchestration and authority. Infrastructure code should describe desired state, while a separate identity-aware service should decide who may obtain which secret and for how long. That distinction is essential for NHI governance because it keeps deployment tooling from becoming the de facto secrets authority. Practitioners should make that boundary explicit in architecture reviews.

Secrets lifecycle governance now spans human, machine, and pipeline identities. A Pulumi workflow touches developer access, CI/CD service accounts, and workload credentials in one path. The useful governance question is not which tool stores the secret, but which identity type is allowed to request, retrieve, rotate, and audit it. Practitioners should map each access path to an owner and lifecycle rule.

From our research:

• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to The 2024 State of Secrets Management Survey.
• Only 44% of organisations are currently using a dedicated secrets management system, which helps explain why stack-level controls so often become the default control boundary.
• For practitioners building beyond Pulumi’s native model, the next step is to study the Guide to the Secret Sprawl Challenge and define where secrets authority should live outside the deployment tool.

What this signals

Secret governance has become an orchestration problem as much as an encryption problem. Teams that let deployment tooling absorb secrets authority often discover too late that they have separate controls for storage, access, and audit. That fragmentation is exactly where programmes lose sight of who can still reach a credential after the original deployment context has changed.

Central auditability is now the minimum viable control for multi-system secrets usage. When a Pulumi stack, a CI/CD job, and a runtime service all touch the same secret, the security team needs a single record of request, issuance, and access. Without that, the organisation may have encrypted secrets but still lack governance clarity.

Static credential trust debt becomes visible fastest in delivery pipelines. Once the same secret is reused across environments, the operational habit becomes the security risk. Programme owners should plan for time-bound credentials, explicit ownership, and outside-in audit evidence before expanding IaC adoption further.

For practitioners

• Map every secret to an owning identity and lifecycle rule Classify each Pulumi secret by the identity that requests it, the system that stores it, and the consumer that uses it. Require an explicit owner, renewal rule, and offboarding trigger for stack secrets, pipeline credentials, and runtime secrets.
• Separate orchestration from secret authority Keep Pulumi responsible for infrastructure state and use a dedicated secrets service for read policy, issuance, and rotation. This avoids turning stack access into blanket access to every credential in the environment.
• Eliminate shared long-lived credentials in deployment paths Replace reusable cloud keys and static database passwords with short-lived credentials wherever the deployment path allows it. Focus first on CI/CD jobs, environment provisioning, and operational access that can be time-boxed.
• Verify cross-platform audit coverage before scaling Pulumi Confirm that secret access from stacks, pipelines, and runtimes lands in one audit trail that can be streamed to your monitoring platform. If each system logs separately, you still lack an end-to-end control picture.

Key takeaways

• Pulumi’s native secrets model protects state, but it does not by itself provide fine-grained secret governance across stacks, pipelines, and runtimes.
• The practical risk is not just exposure, but durable blast radius from static credentials that remain valid across multiple delivery systems.
• Teams that want production-grade control need a separate secrets authority for access policy, rotation, and audit, with Pulumi left to orchestrate infrastructure only.

Key terms

• Secrets sprawl: Secrets sprawl is the growth of credentials, tokens, and keys across too many systems, teams, and deployment paths to govern consistently. It usually appears when each platform manages its own copies, leaving no reliable way to prove scope, ownership, or rotation across the full environment.
• Stack-level access control: Stack-level access control is a coarse permission model where access is granted to an entire infrastructure stack rather than to individual secrets or resources. In IaC environments, it simplifies administration but often prevents least-privilege access and makes auditing harder when many identities share the same stack.
• Dynamic secret: A dynamic secret is a credential generated on demand for a specific consumer, purpose, or time window. Unlike static secrets, it can expire automatically and be tied to a narrower access scope, which reduces blast radius if it is exposed or misused.
• Cross-platform audit trail: A cross-platform audit trail is a single record of secret access and modification across stacks, pipelines, workloads, and operator sessions. It matters because isolated logs cannot show whether a credential was accessed legitimately in one system and reused improperly in another.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step ESC provider setup for authentication and secret retrieval in Pulumi workflows
• Kubernetes operator and External Secrets Operator integration details for syncing runtime credentials
• Certificate lifecycle automation examples for teams managing X.509 alongside infrastructure
• PAM workflow specifics for accessing databases and servers without exposing static passwords

👉 The full Infisical post covers the implementation details, integration steps, and lifecycle controls behind the architecture.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.