Notifications
Clear all
Topic starter
08/07/2026 6:54 pm
TL;DR: Pulumi’s built-in secrets model encrypts values in state, but it still leaves teams with stack-level access, manual rotation, and limited cross-platform audit coverage, according to Infisical’s analysis. The deeper issue is that infrastructure workflows treat secrets as static artefacts even when production access now depends on short-lived, centrally governed credentials.
NHIMG editorial — based on content published by Infisical: Pulumi Secrets Management, Securing Credentials Across Stacks and Pipelines
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
Questions worth separating out
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.
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.
Q: What do teams get wrong about encrypted secrets in infrastructure code?
A: They confuse encryption with governance.
Practitioner guidance
- 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.
- Separate orchestration from secret authority Keep Pulumi responsible for infrastructure state and use a dedicated secrets service for read policy, issuance, and rotation.
- 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.
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
👉 Read Infisical’s full analysis of Pulumi secrets management across stacks and pipelines →
Pulumi secrets management: where stack-level controls break down?
Explore further
08/07/2026 7:16 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Pulumi secrets management shows why stack-level controls fall short
