By NHI Mgmt Group Editorial TeamBased on Teleport: “How to Use Teleport and GitHub Actions to Deploy to Kubernetes Without Shared Secrets” (August 5, 2026)

TL;DR: Teleport shows that GitHub Actions deployments to Kubernetes still rely on privileged, long-lived credentials unless teams replace shared secrets with short-lived workload identities, because secret managers, logs, and CI supply chains can all expose the same access path. Secretless design changes the control point from secret storage to issuance, scope, and revocation.

At a glance

What this is: This is a Teleport walkthrough of deploying to Kubernetes from GitHub Actions without shared secrets, with the key finding that long-lived CI credentials remain the weak point even when they are stored in a secret manager.

Why it matters: It matters because IAM, PAM, and platform teams need to govern machine access around identity issuance and RBAC scope, not just around where a secret is stored.

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

Context

GitHub Actions deployments to Kubernetes depend on machine identities and the privileges attached to them, which makes deployment access a governance problem as much as a tooling problem. The primary issue is not whether a secret is hidden in a vault, but whether the deployment path still depends on a reusable credential with broad cluster authority.

Teleport’s example shows the difference between storing a shared secret and eliminating it. The article ties secretless deployment to short-lived identity documents, Kubernetes RBAC, and Teleport role-based impersonation, which is the right framing for NHI governance in CI/CD.

For teams running Kubernetes delivery pipelines, the control question shifts from “where do we keep the credential?” to “what identity is trusted to deploy, for how long, and with what scope?” That is a more durable way to reduce blast radius across CI/CD, workload identity, and internal API access.

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 long-lived Kubernetes credentials increase security risk?

A: Long-lived credentials extend the window in which stolen or over-scoped access can be reused across cluster resources. They also weaken accountability because the same credential can be shared, copied, or reused outside its intended context. In Kubernetes, short-lived, identity-bound access reduces the chance that an old entitlement becomes a standing foothold.

Q: What are the signs that a secretless CI/CD design is not actually secure?

A: Look for broad Kubernetes roles, unbounded join rules, workflow tokens that are valid too long, and third-party actions that can read environment variables or logs. If the pipeline still trusts static permissions more than run-specific claims, the design has only moved the secret, not removed the risk.

Q: How should teams govern machine identity for GitHub Actions deployments?

A: Treat the workflow as a governed NHI with explicit ownership, scoped RBAC, time-bounded authentication, and revocation paths for the bot and its join token. The practical test is whether the identity can be traced, constrained, and removed without touching unrelated workloads.

Technical breakdown

Why shared CI/CD secrets stay exposed

A deployment pipeline often needs create, update, and delete rights in Kubernetes, which means the credential attached to it is usually far more powerful than a human engineer’s day-to-day access. Once that credential exists, it can be stolen from a developer laptop, a secret manager, pipeline logs, or a compromised third-party action. Secret storage reduces exposure but does not remove the trust problem, because the same identity still exists and can still be reused until rotation catches up.

Practical implication: govern deployment identities as high-value NHI credentials, not as ordinary application configuration.

How short-lived workload identity changes the trust model

The secretless pattern replaces a reusable credential with a short-lived identity document, typically a signed token containing claims about the run, repository, and branch. GitHub Actions OIDC tokens are an example of this model: the CI provider signs the token, and the downstream system verifies the signature and the claims before issuing a downstream certificate. That changes trust from possession of a secret to proof of a specific workload context, which is a much narrower authorization basis.

Practical implication: validate workload claims before issuing downstream access instead of relying on stored deployment secrets.

How Kubernetes RBAC and Teleport roles constrain deploy access

The article’s Kubernetes setup separates authentication from authorization. Kubernetes RBAC scopes the deployment role to specific verbs and namespaces, while the Teleport role further restricts which clusters, groups, and resources the bot may access. This layered design matters because even a legitimate CI identity should not inherit cluster-wide rights by default. The result is a tighter boundary between identity proof, group impersonation, and the actual Kubernetes object set being changed.

Practical implication: align cluster RBAC, Teleport role mapping, and namespace scope so the bot can only touch the deployment surface it needs.

Threat narrative

Attacker objective: The attacker wants to turn deployment access into control over the Kubernetes environment, including the ability to plant malicious workloads or extract cluster secrets.

  1. Entry occurs when a CI/CD credential is exposed through a developer endpoint, pipeline log, or compromised supply-chain component rather than through the Kubernetes API itself.
  2. Credential access follows when the attacker obtains a long-lived secret or shared token that can authenticate as the deployment workflow.
  3. Escalation happens because the deployment identity usually has broad rights to create, update, and sometimes delete Kubernetes resources, which lets the attacker change runtime state.
  4. Impact is malicious deployment, secret extraction, or service disruption inside the cluster using legitimate-looking deployment access.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Long-lived deployment secrets are a governance failure, not a storage failure. The article correctly treats secret managers as only one layer in the exposure chain, because the credential can still be stolen from logs, laptops, or compromised tooling. That means the real problem is the persistence of a reusable deployment identity with broad authority. For NHI governance, the control objective is to reduce the lifetime and reuse value of the credential itself.

Secretless CI/CD changes the control point from possession to context. Short-lived workload tokens force the authorisation decision to depend on the run, the repository, and the branch rather than on a static secret. That is a better fit for NIST CSF access management and OWASP NHI because the privileged identity becomes verifiable and bounded. The implication is that teams should stop treating deployment secrets as configuration artefacts and start treating them as governed machine identities.

Identity blast radius is the decisive variable in pipeline security. When a deployment credential can create, update, and delete cluster resources, the damage from compromise is determined more by scope than by the secrecy of the token. The article’s role and namespace scoping shows how much risk sits in overbroad machine privilege. Practitioners should measure deployment access by what a stolen identity can change, not by where it is stored.

Machine authentication and human authentication are now diverging in practice. The article contrasts passkeys and SSO for people with joining and signed identity documents for machines, which is the right governance split. Human IAM can tolerate interactive flows that machines cannot. The implication is that identity programmes must stop forcing human-centric authentication patterns onto CI/CD workloads and instead govern machines through workload identity and certificate issuance.

Secretless deployment is only credible when offboarding and revocation are real. A short-lived token is better than a shared secret, but the broader lifecycle still matters because roles, join tokens, and bot identities can outlive their intended use if not revoked. This is where NHI lifecycle governance becomes operational, not theoretical. Practitioners should treat bot enrolment, token rules, and role scope as revocable assets with explicit ownership.

From our research library:

What this signals

Secretless deployment only works when the identity layer is narrower than the deployment layer. If a CI workflow can still authenticate with a reusable token, the organisation has changed storage mechanics but not trust mechanics. The next programme decision is whether the same model can govern database access and internal API calls without reintroducing shared credentials.

Identity blast radius should become a standard measurement for CI/CD risk. In pipeline security, the question is no longer whether a secret exists somewhere in the stack, but how much state a stolen workflow identity can change before it is revoked. That makes scope, expiry, and traceability more operationally important than vault placement.

Shared-secret reduction is now a multi-surface governance issue. The same pattern that protects Kubernetes deployments can also govern internal API access and database tunnels, but only if workflow claims, role scope, and offboarding are managed consistently across those targets.

For practitioners

  • Define deployment identities as first-class NHIs Inventory every GitHub Actions workflow that can deploy, migrate, or mutate Kubernetes state and name the bot, token, or role that authorises it.
  • Replace reusable secrets with short-lived workload tokens Use signed OIDC-style claims and certificate issuance for pipeline authentication so the deploy identity expires with the job, not with a manual rotation cycle.
  • Scope Kubernetes RBAC to the exact deployment surface Limit verbs, namespaces, and resource kinds to the minimum set the workflow needs, then keep cluster-wide privileges out of CI/CD by default.
  • Bind Teleport roles to explicit branch and repository claims Require the join token and bot policy to match the intended repository and branch so a valid CI run cannot be reused outside its approved context.
  • Audit third-party actions for secret-handling exposure Review every external action in the workflow for credential leakage paths, because supply-chain compromise of CI tooling can still expose downstream deployment trust.

Key takeaways

  • The article frames CI/CD as an identity security problem because deployment credentials often carry enough privilege to change cluster state, not just authenticate a job.
  • Its core evidence is that long-lived shared secrets can be stolen from logs, laptops, or supply-chain tools even when they are stored in a manager.
  • The limiting control is not secret storage alone but short-lived workload identity combined with narrow RBAC and explicit revocation paths.

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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-02 — Secret LeakageThe article centres on CI/CD secrets leaking from logs, tools, and workstations.
NHI-05 — Overprivileged NHIThe deployment identity needs broad Kubernetes rights unless RBAC is tightly scoped.
NHI-07 — Long-Lived SecretsThe article argues that weekly or monthly rotation still leaves an exploitable window.
Recommendation — Scan deployment workflows for leaked secrets and replace exposed credentials with short-lived identities. Reduce CI/CD identity scope to the minimum verbs, namespaces, and resources the workflow actually needs. Eliminate long-lived deployment secrets and issue short-lived credentials tied to each run.
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementCredential lifecycle and rotation are central to the article’s shared-secret critique.
AC-6 — Least PrivilegeThe article repeatedly stresses minimizing the Kubernetes permissions granted to CI jobs.
Recommendation — Apply authenticator lifecycle controls to rotate and revoke deployment credentials on a governed schedule. Constrain deployment roles to least privilege and avoid cluster-wide rights for pipeline identities.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article focuses on entitlement scope for machine identities in CI/CD.
Recommendation — Review and enforce machine access permissions so pipeline identities cannot exceed their intended authorization scope.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementThe attack pattern described is secret theft followed by movement into the Kubernetes environment.
Recommendation — Map pipeline secret exposure to credential access and follow through on downstream lateral movement paths.

Key terms

  • Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
  • 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.
  • Kubernetes RBAC: Kubernetes RBAC is the permission system that decides what users, groups, and service accounts can do inside a cluster. It uses roles and cluster roles, then binds them to subjects so access is limited to specific resources, verbs, and namespaces, reducing unnecessary control over workloads and infrastructure.
  • 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 blog post covers the operational detail this post intentionally leaves for the source:

  • Step-by-step YAML for Kubernetes Role, RoleBinding, Teleport role, and bot setup
  • GitHub Actions workflow configuration for OIDC-backed deployment authentication
  • How Teleport verifies GitHub claims, mints certificates, and records audit events
  • Examples of extending the same secretless pattern to database tunnels and internal APIs

👉 Teleport's full post covers the Kubernetes RBAC, join token, and Machine ID workflow details behind the secretless pattern.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 17, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org