They often hold the same credentials used to provision, deploy, and administer clusters, but they are typically treated as less sensitive than the control plane. That mismatch creates a path from package execution to cluster access. When those hosts can run untrusted code, the real attack surface includes identity material, not just software artifacts.
Why the risk is not just “runner hardening”
CI/CD runners and developer workstations expand Kubernetes risk because they often sit on the path that creates, signs, deploys, and administers clusters. If those hosts can execute untrusted code, the attacker is no longer limited to tampering with build output, they can target the credentials and session material on the host itself. That turns a software execution problem into a cluster trust problem.
The important distinction is privilege concentration. These endpoints may have direct or indirect access to kubeconfigs, cloud tokens, signing material, deployment secrets, or admin APIs, so compromise of the endpoint can inherit the authority needed to reach Kubernetes. Treating them as ordinary developer laptops or transient build boxes understates how much control they may carry.
A practical way to think about the exposure is that the runner or workstation becomes a bridge between untrusted code and privileged cluster actions. That bridge is especially dangerous when long-lived credentials are cached, reused across environments, or mounted into jobs that are expected to process third-party dependencies.
How Kubernetes compromise happens through the build-and-dev path
The compromise path usually starts with code execution on the runner or workstation, then moves to secret discovery, token reuse, and authenticated access to cluster or cloud control surfaces. Once an attacker can read environment variables, mounted files, credential helpers, browser sessions, or local key material, they can often pivot from the endpoint into deployment systems that were assumed to be “behind” the cluster boundary.
This is why build systems and developer machines are security-relevant even when the cluster itself is well configured. If the endpoint can mint or replay the same credentials used for provisioning or administration, the attacker can impersonate trusted automation, push altered manifests, or manipulate deployments without needing to break Kubernetes directly.
The exposure becomes broader when runners are persistent, shared across projects, or allowed to execute third-party actions and packages. In those cases, the host is not just compiling code, it is acting as a high-value trust broker. That is the kind of surface that CI/CD Pipeline Identity Security Guide is built to help teams reason about, especially where identity material and untrusted builds intersect.
Why identity material on endpoints matters more than artifact integrity alone
Kubernetes compromise via CI/CD rarely requires a novel cluster exploit if the attacker can steal the identity material already present on the endpoint. The real issue is not only whether a package or container image is trusted, but whether the host that builds or deploys it can be coerced into revealing the credentials that make deployment possible.
That is why secret hygiene, token lifetime, and workload isolation matter so much in this path. If a runner can access reusable tokens, if a workstation caches cloud sessions, or if credentials are broadly scoped, the attacker can move from “code execution in a job” to “authenticated actor in the cluster” with very little friction. Guide to the Secret Sprawl Challenge is relevant here because secret sprawl is the mechanism that makes these endpoints disproportionately dangerous.
Containers and runners also widen the blast radius when secrets are mounted into builds for convenience. Once a job can inspect its own environment or filesystem, any credential placed there becomes part of the attack surface. For teams running containerised build infrastructure, NIST SP 800-190 Container Security provides the right mental model for host, image, orchestrator, and runtime exposure.
Risk and Threat Considerations
These hosts are attractive to attackers because they often combine execution rights with deployed trust. A single compromise can yield not only source access, but also tokens, signing keys, deployment credentials, and paths into production Kubernetes control planes. The failure is usually not Kubernetes itself, it is the assumption that the machine used to reach Kubernetes is less sensitive than the cluster.
Failure mechanism: Untrusted code on the runner or workstation reads cached secrets, session tokens, kubeconfigs, or cloud credentials, then reuses them to authenticate to cluster or cloud APIs.
Impact: Attackers can change deployments, escalate privileges, access namespaces and workloads, and persist through trusted automation even after the original host compromise is remediated.
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 OWASP API Security Top 10 address the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Runner and workstation compromise often starts with exposed credentials and tokens. |
| NHI-05 — Overprivileged NHI | CI/CD and workstation identities often carry more Kubernetes access than they need. | |
| NHI-07 — Long-Lived Secrets | Persistent kubeconfigs and cloud tokens make endpoint compromise reusable against clusters. | |
| Recommendation — Reduce secret exposure on build and dev hosts and rotate credentials after any compromise. Scope automation identities to the minimum cluster and deployment permissions required. Replace long-lived deployment secrets with short-lived, automatically rotated credentials. | ||
| CIS Controls v8 | CIS-5 — Account Management | Build and admin identities on runners and workstations need strong lifecycle and access control. |
| CIS-6 — Access Control Management | The question is fundamentally about controlling who can reach Kubernetes through trusted endpoints. | |
| Recommendation — Inventory and restrict privileged accounts and service credentials used on build endpoints. Enforce least privilege and remove unnecessary Kubernetes access paths from endpoints. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The risk depends on how credentials and tokens are protected on the host. |
| AC-6 — Least Privilege | Compromised endpoints become dangerous when they can deploy or administer clusters broadly. | |
| Recommendation — Manage authenticator lifetime, storage, and rotation for runner and workstation credentials. Limit runner and developer access to the minimum Kubernetes actions required. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Many CI/CD and workstation access paths rely on federated tokens and assertions. |
| Recommendation — Use strong federation and token handling for automation and deployment access. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | When tokens stolen from endpoints authenticate to cluster APIs, authentication becomes the pivot point. |
| API5 — Broken Function Level Authorization | Stolen endpoint credentials can reach privileged cluster functions if authorization is too broad. | |
| Recommendation — Harden token handling for any API that accepts credentials from build or admin endpoints. Verify that deployment and cluster functions enforce function-level authorization. | ||
Practitioner Guidance
What to prioritise: Treat runner and workstation credentials as production-grade assets, not convenience tokens. The first question is whether the host can authenticate to cluster-admin, cloud-admin, or signing workflows, because that defines the blast radius if it is compromised.
What to verify: Check whether jobs can reach secrets they do not strictly need, whether credentials are short-lived, and whether the runner can execute untrusted dependencies without exposing the same identity material used for deployment. If the answer is yes, the host is part of the control plane path and should be managed accordingly.
Practitioner takeaway: Kubernetes compromise risk rises sharply when build and developer endpoints inherit trusted access, because endpoint compromise then becomes an authenticated control-path compromise, not just a code-execution event.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org