What breaks when Pulumi secrets are governed only at the stack level?

Why stack-only secret governance breaks in shared deployments

Stack scope is a convenient default, but it is too coarse when a single Pulumi deployment boundary serves multiple actors and trust levels. If pipelines, operators, and application runtimes all inherit the same secret reach, the stack becomes the access unit instead of the actual security boundary. That is where least privilege starts to fail, even if the configuration looks tidy.

In practice, the break happens because the stack does not distinguish who needs a secret, when they need it, or for how long. A build pipeline may only need a short-lived value during deployment, while a runtime may need ongoing read access, and an operator may need break-glass access with approval. Stack-level governance collapses those differences into one shared permission set.

That is why shared production environments tend to expose the weakness first. The more teams, tools, and automation paths share a stack, the harder it becomes to justify broad secret visibility as an acceptable control choice. In Secrets Management Guide, the practical fix is not just centralisation, but separating secret delivery from broad stack access so the right principal gets the right secret at the right time.

What changes when secrets need different scopes, lifetimes, and approval paths

Once secret access needs differ by principal, stack-level governance is no longer enough on its own. The control problem shifts from “is the secret inside the stack?” to “which identity can retrieve this value, under what conditions, and with what revocation path?” That is a broader access-governance question, not just a storage question.

This is also where secret type matters. A deployment token, an application API key, and an operator break-glass credential often deserve different rotation cadences, blast radii, and monitoring thresholds. Treating them as one stack-scoped bucket hides those differences and makes it harder to rotate or revoke one secret without disturbing unrelated workflows.

For teams standardising secret handling, API Key Management Guide is useful because it frames scoping, rotation, and revocation as lifecycle decisions, not merely storage decisions. When the governance model cannot express those lifecycle differences, the control is too blunt for production.

That same pattern shows up in the broader non-human identity model. Ultimate Guide to NHIs explains why service accounts, tokens, and other machine-access paths need their own ownership and authority model, because the entity using a secret is often not the same entity that should govern it.

How practitioners should redesign the control boundary

Start by deciding whether the stack boundary is still the right security boundary. If the answer is no, move secret access closer to the consuming principal and the specific stage that needs it. That usually means separating build-time, deploy-time, and runtime access rather than assuming one stack policy can safely cover all three.

What to verify: confirm that each secret has an explicit owner, a defined consumer, and a revocation path that does not depend on tearing down the whole stack. If you cannot rotate one secret without disrupting unrelated workloads, the boundary is still too coarse.

Common mistake: teams often treat “stack access” as equivalent to “need to know.” In shared production, those are not the same, and the difference determines whether a compromise stays narrow or becomes deployment-wide.

What good looks like: secrets are exposed only to the smallest workable set of principals, access is time-bounded where possible, and production operators do not inherit the same secret scope as CI/CD automation by default.

Practitioner takeaway: stack-level governance is acceptable only when the stack itself is the real trust boundary; once multiple principals share it, secret handling has to become principal-specific or least privilege is lost.

Risk and Threat Considerations

When one stack grants broad secret visibility, compromise or misuse of any principal in that stack can expose everything else in the same boundary. That turns a single weak pipeline, operator account, or runtime path into a much larger credential-loss problem, especially in shared production environments.

Failure mechanism: the access boundary is too coarse, so secret retrieval is not separated by role, lifetime, or purpose. An attacker or insider who reaches any stack-level principal can often move from one approved use case to broader secret access without needing another control break.

Impact: the likely consequence is larger blast radius, faster secret reuse after compromise, and harder incident response because rotation, revocation, and attribution all become coupled to the stack rather than to the specific secret or principal.

Practitioner Guidance

Decision rule: if a secret is needed by different classes of principal, do not let stack membership be the only control. Split access by consumer and stage, and require a separate approval or delivery path for higher-risk secrets.

What to measure: track how many secrets are readable by more principals than actively need them, and treat that as an access-governance defect rather than an ops convenience.

What to prioritise: production first, especially stacks that mix CI/CD, operators, and long-running workloads. Test and demo stacks can tolerate broad access far more easily than shared deployment boundaries.

Practitioner takeaway: the right question is not whether the secret is in the stack, but whether the principal that can read the stack genuinely deserves every secret inside it.

Related resources from NHI Mgmt Group

• Why do collaboration tools create such a large secrets risk?
• Why do leaked secrets remain such a persistent NHI risk?
• What makes idle secrets such a serious NHI risk?
• What should security teams do about secrets hidden in SharePoint?