Notifications
Clear all
Topic starter
17/08/2026 4:37 pm
TL;DR: Shared Kubernetes credentials in CI/CD pipelines create a durable attack surface that short-lived identities are meant to shrink, but Teleport’s analysis shows the real issue is the trust model behind deployment access, not just secret storage, according to Teleport. When machine identity replaces shared secrets, privilege scope, auditability, and revocation move from afterthoughts to the core control plane.
NHIMG editorial — based on content published by Teleport: How to Use Teleport and GitHub Actions to Deploy to Kubernetes Without Shared Secrets
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations.
Questions worth separating out
Q: What breaks when Kubernetes deployments still depend on shared CI/CD secrets?
A: Shared deployment secrets turn a pipeline into a standing access path.
Q: Why do short-lived machine identities reduce CI/CD risk more than secret rotation alone?
A: Rotation only shortens the lifetime of a reusable credential after it already exists.
Q: How do security teams know whether pipeline access is actually under control?
A: Look for three signals: no long-lived deploy secrets in repository or pipeline settings, tight Kubernetes roles scoped to the smallest viable namespace and verbs, and audit logs that tie each deploy to a specific workflow run.
Practitioner guidance
- Map deployment identities as governed NHIs Inventory every CI/CD workflow that can reach production, then assign an owner, purpose, expiry expectation, and revocation path to each identity.
- Replace reusable secrets with runtime attestation Use short-lived OIDC or equivalent attested tokens where the platform supports them, and block workflows that still depend on manually stored deployment secrets.
- Constrain Kubernetes access by namespace and resource Bind CI jobs to the minimum Kubernetes Role needed for the manifest set they deploy, then avoid ClusterRole unless the workflow truly requires cluster-wide reach.
What's in the full article
Teleport's full article covers the implementation detail this post intentionally leaves for the source:
- Step-by-step YAML for the Kubernetes Role, RoleBinding, Teleport role, bot, and join token used in the example workflow.
- The exact GitHub Actions job configuration, including the Teleport auth step and kubectl deployment step.
- The join-token claim structure that limits authentication to a specific repository and branch.
- The full explanation of how Teleport turns the short-lived identity token into a certificate and session audit trail.
👉 Read Teleport's guide to secretless Kubernetes deployments from GitHub Actions →
Kubernetes secretless deployments: what changes for IAM teams?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 4:43 pm
Secretless CI/CD is really a governance model for deployment identities: the article is not about removing secrets alone, but about removing reusable privilege from the delivery path. A Kubernetes deployer is a non-human identity with a lifecycle, blast radius, and revocation need just like any other machine account. Once teams see CI/CD through that lens, the question becomes whether the pipeline identity is bounded tightly enough to be safe when stolen, not whether the secret is hidden in a better vault.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
A question worth separating out:
Q: Should organisations use the same governance model for CI/CD identities as for service accounts?
A: Yes, because both are non-human identities performing production work under delegated privilege. The governance mechanics are nearly identical: ownership, scope, expiry, review, and revocation. The difference is that CI/CD identities are often more exposed to supply chain and log-based theft, so their controls should usually be stricter.
👉 Read our full editorial: Secretless GitHub Actions deployments expose the limits of shared secrets
