What breaks when a CI/CD namespace is deleted but its cloud trust remains?

The trust relationship outlives the identity source. A cloud role that still accepts an OIDC subject from a deleted namespace can be assumed by whoever reclaims that namespace, which turns a normal lifecycle event into a reusable access path. The failure is stale authorization, not token forgery.

What actually breaks in this lifecycle mismatch?

The break is not token forgery, it is trust persistence. When a CI/CD namespace is deleted, any cloud role that still trusts its OIDC subject can remain callable through that stale relationship. The identity source is gone, but the authorization path is still valid, so namespace reclamation becomes an access-reuse event instead of a clean teardown.

That matters because the cloud side is usually the enforcement point. If the trust policy, subject claim, or audience binding still matches, the role does exactly what it was told to do, even if the original namespace no longer exists. In practice, the deleted namespace is only half the cleanup.

For CI/CD systems that use keyless federation, the security boundary is the trust mapping between the workload identity and the cloud role. A namespace deletion removes one side of that boundary, but it does not automatically revoke the other side. The result is a stale entitlement that can outlive the platform object that once anchored it.

Why namespace deletion can become reusable access

The dangerous condition is namespace reuse. If a new tenant, team, or project later claims the same namespace name, and the cloud trust still accepts that namespace as a valid OIDC subject, the new owner can inherit the old role path. That is a lifecycle failure in the trust relationship, not a flaw in OIDC itself.

This is closely related to workload identity and keyless CI/CD patterns documented in Cloud Workload Identity Guide and CI/CD Pipeline Identity Security Guide. If you treat the namespace as an ephemeral implementation detail but the cloud role as a durable entitlement, you create a gap where lifecycle and access do not end together.

That same pattern is why SPIFFE workload identity specification is useful here as a reference point: the core problem is the durability of trust anchors and subject bindings, not just the presence of an identity string. The lesson is to make the trust relationship expire or become unresolvable when the workload boundary disappears.

What this means for cleanup, rotation, and trust design

Deleted namespaces should trigger revocation of every downstream trust that references them, including cloud roles, federated subjects, deployment tokens, and any policy that keys access off the namespace path. If the namespace can be recreated, the trust rule needs an additional control, such as stronger issuer scoping, unique immutable identifiers, or explicit lifecycle hooks that remove the role binding at deletion time.

Keyless CI/CD designs are safer when cloud trust is bound to an identity that cannot be casually reclaimed. That can mean immutable workload IDs, short-lived bindings, or policy logic that requires more than a human-readable namespace name. The practical goal is to ensure the trust anchor fails closed when the source namespace is retired.

For implementation detail, SLSA helps frame this as a supply-chain integrity issue: the build pipeline is only trustworthy if the provenance path and its authorization boundaries are controlled across the full lifecycle. Namespace deletion is not an integrity event by itself, but it should be one of the revocation triggers that closes the provenance chain.

Risk and Threat Considerations

Stale federated trust can turn routine platform churn into unauthorized access. The risk is highest when namespace reuse is possible, cloud roles are broad, and deletion workflows do not revoke every dependent trust relationship. In that case, a normal cleanup event can leave behind a working access path for a later occupant of the same namespace.

Failure mechanism: The cloud trust policy still matches an OIDC subject or claim after the namespace is deleted, so the old authorization path remains valid and can be reclaimed by a future namespace owner.

Impact: Attackers or unintended tenants can inherit production access, reuse privileged deployment roles, and bypass the intended lifecycle boundary without stealing a token or breaking authentication.

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, CIS Controls v8 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-01 — Improper Offboarding	Deleted namespaces leaving active trust is an offboarding failure for non-human workload identities.
	NHI-09 — NHI Reuse	A reclaimed namespace can inherit the old subject binding and reuse prior access.
	NHI-05 — Overprivileged NHI	A stale cloud role can remain broadly assumable after the source namespace is gone.
Recommendation — Revoke cloud trust and dependent bindings when the namespace or workload is decommissioned. Bind trust to immutable workload identifiers so recreated namespaces cannot inherit old access. Reduce role scope so stale trust cannot expose unnecessary production privileges.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Federated trust material and its lifecycle must be managed and revoked when no longer valid.
	AC-2 — Account Management	Cleanup must remove inactive or retired access relationships, not only source objects.
	AC-6 — Least Privilege	Stale roles are dangerous because they preserve access beyond the intended lifecycle.
Recommendation — Rotate or revoke federation material when the source identity lifecycle ends. Disable dependent access paths when the workload or namespace is deleted. Constrain federated roles to the minimum permissions needed for the pipeline.
CIS Controls v8	CIS-5 — Account Management	Lifecycle cleanup of accounts and access relationships is central to preventing stale trust reuse.
Recommendation — Remove cloud access relationships as part of namespace retirement workflows.
NIST Zero Trust (SP 800-207)	AC-6 — Least Privilege Access for Subjects and Resources	Zero Trust requires continuous validation, not permanent trust after the source disappears.
Recommendation — Treat federated trust as conditional and short-lived rather than permanently reusable.
ISO/IEC 27001:2022	A.5.16 — Identity Management	Identity relationships must be governed across their full lifecycle, including retirement.
Recommendation — Ensure identity bindings are deleted or invalidated when the namespace is removed.

Practitioner Guidance

What to verify: Confirm that namespace deletion triggers explicit removal of every cloud role trust, subject binding, and federation policy that references that namespace. If the cleanup is only deleting the Kubernetes object, the control is incomplete.

Decision rule: If a cloud role can still be assumed after the namespace no longer exists, treat that as a revocation defect, not an acceptable residual risk. The fix is to close the trust relationship, not to wait for a compromise signal.

What good looks like: A deleted namespace leaves no reusable cloud trust behind, and any recreated namespace must earn a fresh, distinct authorization path rather than inheriting the old one.

Practitioner takeaway: The security objective is lifecycle symmetry, identity removal and trust revocation must happen together, or deletion becomes a deferred access control failure.