Secretless GitHub Actions deployments expose the limits of shared secrets

At a glance

What this is: This is a Teleport article on replacing long-lived Kubernetes deployment secrets in GitHub Actions with short-lived machine identity and Teleport-mediated access.

Why it matters: It matters because IAM, PAM, and NHI teams have to govern CI/CD credentials as production identities, not as incidental pipeline variables, or deployment paths become an easy privilege-escalation route.

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.
• 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.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations.

👉 Read Teleport's guide to secretless Kubernetes deployments from GitHub Actions

Context

Kubernetes deployments increasingly depend on CI/CD identities with enough privilege to create, update, and sometimes delete production resources. That makes the deployment path an identity problem, not just a delivery problem, because any long-lived credential embedded in the pipeline can become a standing bridge into cluster access.

The article argues for replacing shared secrets with short-lived machine identity issued at runtime and constrained through Kubernetes RBAC plus Teleport roles and join rules. This is the right governance question for NHI programmes: how to preserve deploy automation while removing reusable credentials from the trust boundary.

For teams already grappling with secret sprawl in pipelines, this maps directly to the same control gap that appears in broader NHI governance work. The challenge is not whether a secret manager exists, but whether the deployment workflow still depends on credentials that remain valid long enough to be stolen, replayed, or repurposed.

Key questions

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. If one credential leaks from logs, a developer laptop, or a compromised action, the attacker can reuse it until expiry and operate with the same privileges as the build job. That makes Kubernetes access a replayable identity problem, not a one-time secret exposure.

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. Short-lived machine identity changes the model by issuing a fresh, attested credential for each run, which reduces replay value and ties access to a specific job context. That makes theft harder to exploit and revocation simpler to reason about.

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. If any one of those is missing, the pipeline still has standing privilege.

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.

Technical breakdown

Why CI/CD credentials become high-value non-human identities

A deployment pipeline needs an identity that can act inside the cluster, which usually means permissions broader than a normal developer account. In Kubernetes, that identity often maps to a service account, role binding, or externally issued certificate that can create, patch, or delete workloads. If the credential is long-lived, the attacker does not need to break the pipeline logic again after initial exposure. They only need the secret once, then can reuse it until expiry or revocation. The real technical issue is that the deployment identity is persistent while the work it performs is ephemeral.

Practical implication: treat CI/CD deployment credentials as governed NHIs with explicit expiry, scope, and revocation paths.

How short-lived OIDC tokens change the trust boundary

GitHub Actions can issue a short-lived OIDC token for each job run, and that token carries claims such as repository, branch, and triggering context. A downstream system can verify the signature using the issuer’s public key and decide whether the run is allowed to exchange that token for a stronger credential. This shifts trust from shared static secrets to signed runtime assertions. The security value is not merely short lifetime. It is that the identity of the job is attested at execution time, which lets policy bind access to a specific workflow invocation rather than to a reusable string stored somewhere else.

Practical implication: replace static deployment secrets with attested runtime identities wherever the platform supports federated token exchange.

Where Kubernetes RBAC and Teleport reinforce each other

Kubernetes RBAC defines what the identity can do inside the cluster, while Teleport adds an intermediate control plane that can map the runtime identity to cluster access, impersonate specific groups, and record activity. That layered model matters because cluster permissions alone do not solve credential distribution. The join process becomes the enforcement point, where workload claims are checked before access is granted. In practice, this gives teams a place to apply namespace scoping, resource scoping, and audit logging together, rather than scattering those controls across the pipeline and the cluster separately.

Practical implication: align cluster RBAC, federation rules, and audit logging so no single pipeline secret becomes the control point.

Threat narrative

Attacker objective: The attacker wants durable production access through the deployment path, not just a single leaked token.

1. Entry occurs when a CI/CD credential or pipeline token is exposed through logs, source control, a compromised developer machine, or a supply chain attack on a build tool.
2. Escalation happens because the credential typically carries deployment-level privilege, allowing the attacker to create, modify, or delete Kubernetes resources and potentially plant malicious workloads.
3. Impact follows when the attacker uses that standing access to extract secrets, intercept traffic, disrupt services, or persist in the cluster through unauthorized workloads.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Long-lived deployment credentials create trust debt: the longer a pipeline secret remains valid, the more attack opportunities accumulate across laptops, logs, build steps, and downstream tools. That is not just exposure, it is compounding residual risk that survives the original control decision. The most useful concept here is trust debt, meaning the accumulated security liability created when a workflow keeps a reusable credential instead of an ephemeral attested identity. Practitioners should treat that debt as a measurable governance problem, not a tooling inconvenience.

CI/CD pipelines are now production workloads and must be governed as such: the article’s model treats GitHub Actions as an actor that can be authenticated, constrained, and audited. That aligns with OWASP NHI thinking, where service identities deserve explicit lifecycle management, scoped privileges, and revocation. The practical consequence is that pipeline access should be reviewed with the same seriousness as any privileged service account, because the deployment path often reaches deeper into production than a human operator ever should.

Secret sprawl in delivery systems is the symptom, not the cause: secrets leak because organisations still design around reusable trust artefacts. Short-lived identity, attestation, and group impersonation reduce the number of places a credential can be copied, but only if the surrounding policy removes unnecessary standing privilege. For IAM and PAM teams, the lesson is that pipeline hardening is really entitlement design, and entitlement design is where the real control boundary lives.

From our research:

• 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.
• Guide to the Secret Sprawl Challenge explains why discovery, rotation, and revocation must be treated as one control loop rather than separate tasks.

What this signals

Trust debt: deployment pipelines that still rely on reusable credentials accumulate hidden governance risk every time a secret is copied into a log, action, or config file. Once teams start measuring that debt, the discussion shifts from incident response to entitlement design, which is where the durable fix lives.

The practical programme change is to treat CI/CD identities as a first-class NHI population. That means joining access reviews, rotation rules, and audit trails to the release process, not bolting them on after a leak. For readers using federated workload identity, the SPIFFE workload identity specification is a useful reference point for how attestation and workload identity can be structured.

Secretless delivery is also a forcing function for PAM teams. When a pipeline can deploy, delete, and patch production resources, the old boundary between human privilege and machine privilege stops being operationally useful, and lifecycle governance has to cover both with the same rigor.

For practitioners

• 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. Do not let pipeline tokens sit outside the same governance process used for other privileged non-human accounts.
• 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. Keep the exchange path narrow so the job identity is validated before any cluster privilege is issued.
• 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. Review delete, patch, and create verbs separately because each expands the blast radius differently.
• Audit pipeline logs and third-party actions for secret exposure Search build logs, action outputs, and script variables for deployment credentials, then pin external actions to known commit SHAs so a supply chain change cannot silently widen the attack surface. This is especially important where the pipeline runs migrations or touches internal APIs.

Key takeaways

• CI/CD deployment credentials behave like high-risk non-human identities, not disposable pipeline settings.
• Short-lived attested identities reduce replay value, but only if Kubernetes RBAC and join policy stay tightly scoped.
• The governance problem is standing privilege in the delivery path, and that needs lifecycle control, not just secret storage.

Key terms

• Deployment Identity: A deployment identity is the non-human identity a CI/CD system uses to reach production resources. In practice, it should be uniquely owned, narrowly scoped, time-bound, and revocable, because it can modify live systems and becomes a high-value target when shared or long-lived.
• Short-Lived Attested Credential: A short-lived attested credential is a token or certificate issued for a specific run or workload after the platform verifies who or what is asking. It reduces replay risk because the credential is only useful within a narrow window and is tied to claims that can be checked at runtime.
• Trust debt: Accumulated security risk created when access assumptions are not revalidated quickly enough for the pace of modern automation. In identity programmes, trust debt appears when roles, secrets, or agent permissions persist longer than the environment that justified them.
• Join Token: A join token is the policy object that governs how a machine or workload is allowed to exchange its runtime identity for downstream access. For CI/CD, it acts as the gatekeeper between attested job claims and the ability to receive a certificate or session credential.

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.

👉 The full Teleport article covers the bot join flow, token claims, and end-to-end workflow configuration.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.