TL;DR
- K03 turns one leak into a chain: Secrets Management Failures let a single exposed token unlock more credentials. GitGuardian found 44 active clusters reachable through leaked secrets, and 30% had been exposed for over two years.
- Pipelines and repositories feed the cluster: GhostAction targeted 2,577 secret values across 772 repositories, and a public CISA-related repo exposed active credentials, showing how continuous integration and continuous delivery (CI/CD) and source control become paths into Kubernetes.
- Shrink the blast radius across the credential layer: Strict RBAC, short-lived workload identity, and credential detection across repos, images, and pipelines limit what any exposed token can reach, with ggshield, AI hooks, and Developer Endpoint Protection preventing new leaks.
Recent attacks make the OWASP Kubernetes Top 10 essential reading
Kubernetes powers modern infrastructure. 82% of container users now run it in production environments, according to the most recent Cloud Native Computing Foundation (CNCF) Annual Cloud Native Survey. For the majority of DevOps teams who want to run their applications in containers, Kubernetes is the first thing they turn to. Kubernetes (K8s) offers many advantages, but it also has potential pitfalls if you don't set everything up correctly. This is why Kubernetes has its own OWASP Top 10.
Kubernetes security risks include workloads, identities, and infrastructure. A compromised container can expose a service account. That service account may have permissions to reach other systems, where it could find additional credentials. Credentials very often provide access to systems far beyond the original cluster.
Recent GitGuardian investigations show how these attack paths work in practice. Researchers discovered leaked credentials that provided access to 44 active Kubernetes clusters. The recent round of GhostAction supply chain campaign targeted thousands of K8 credentials through GitHub Actions. Another investigation uncovered a public repository containing CISA-related infrastructure configurations and active credentials.
With so much going on in the threat landscape targeting it, we think it is a good time to review the OWASP Kubernetes Top 10. Its ten categories identify the weaknesses that allow attackers to enter Kubernetes environments, expand their permissions, and reach connected infrastructure.
The 10 Kubernetes security risks in the OWASP list
The OWASP Kubernetes Top 10 gives a prioritized view of the most pressing risks affecting Kubernetes environments. These risks are not theoretical, but real-world issues the community is reporting and working on. This includes insecure configurations, weak access controls, and failures in protecting sensitive resources.
These risks frequently overlap. A compromised workload may expose credentials with excessive permissions. Those permissions may allow an attacker to access additional workloads or cloud resources.
K01: Insecure Workload Configurations
Privileged containers, excessive Linux capabilities, and dangerous host mounts can give workloads more access than they require. Attackers who compromise these workloads may gain access to sensitive files or underlying infrastructure.
K02: Overly Permissive Authorization Configurations
Role-Based Access Control (RBAC) determines what users and service accounts can access in Kubernetes. Excessive permissions increase the authority available to compromised identities, including the ability to retrieve Kubernetes Secrets or modify workloads.
K03: Secrets Management Failures
K03 covers Kubernetes secrets management failures. Applications depend on credentials to connect: API keys, passwords, and tokens, which can leak in plaintext through repositories, container images, and application configurations. Long-lived credentials and other weak authentication schemes increase their usefulness to attackers.
K04: Lack of Cluster-Level Policy Enforcement
Admission policies can help enforce security requirements across workloads. While it should be standard for each action to be within policy, inconsistent enforcement allows dangerous configurations and excessive privileges to reach production environments.
K05: Missing Network Segmentation Controls
Kubernetes network policies restrict communication between workloads to what is configured correctly. Weak or missing segmentation can allow attackers to move between services after compromising an application. This is particularly dangerous when valid credentials provide access. If an attacker can get access, they should impact the smallest blast radius possible.
K06: Overly Exposed Kubernetes Components
The more of the cluster is reachable from the internet, the larger the advantage the attacker has. Exposed API servers and administrative interfaces increase opportunities for unauthorized access. Attackers may exploit vulnerable components or use stolen credentials to interact with cluster management services.
K07: Misconfigured and Vulnerable Cluster Components
There are a lot of ways to misconfigure Kubernetes, but also a lot of ways to get things correct. This is the challenge of deploying open source in general. We must get it right and apply regular updates. Vulnerabilities can provide attackers with access to infrastructure or opportunities to increase their privileges.
K08: Cluster to Cloud Lateral Movement
Kubernetes workloads often use cloud identities and credentials. This gives clusters the power to be useful, but there is a lot of danger here. Excessive cloud permissions can allow attackers who compromise a workload to access resources outside the cluster.
K09: Broken Authentication Mechanisms
When an attacker compromises a system, they can break in, or they can simply log in. Weak authentication controls and poorly protected service account tokens can let attackers impersonate trusted identities and gain permissions that are often set too broadly. Stolen credentials may provide the same access as the legitimate workload or user.
K10: Inadequate Logging and Monitoring
If an attack happens, how would you know and how would you prove that? Security teams need visibility into authentication events, API requests, and changes to sensitive resources. Without sufficient monitoring, credential misuse and unauthorized activity are much harder to detect and prove. Auditors need to know when you knew about the issue and what you did.
Why K03 deserves special attention
For K03, Secrets Management Failures, OWASP supplies guidance identifying six common ways credentials become exposed.
- Secrets in container images: Credentials get baked into an image or one of its layers. Anyone who can access the image may be able to recover the secret, and rotation becomes much harder.
- Secrets in ConfigMaps: Sensitive values are placed in ConfigMaps, which often have weaker access controls and are more likely to appear in backups or debugging output.
- Secrets in environment variables - Secrets passed as environment variables can surface in debugging data, process information, crash reports, or other diagnostic output.
- Secrets in code repositories: Credentials committed to source code can spread through clones, forks, CI systems, developer machines, and other copies of the repository.
- Excessive
WATCHorLISTaccess to Secrets: A Kubernetes identity withLISTorWATCHpermissions on Secret objects can effectively retrieve those secrets at scale. This turns an overly broad RBAC permission into a credential exposure path. - Secrets in application logs: Applications can accidentally write credentials to
stdoutorstderr, especially when logging configuration or environment state. Those secrets may then spread into centralized logging systems such as Splunk or Elasticsearch and remain there for long periods.
There are a lot of ways and places these issues can be introduced. Developers may add credentials to Dockerfiles during testing. Automation systems may receive powerful service account tokens. Applications may log sensitive environment variables while diagnosing errors.
Each exposure can give an attacker usable credentials.
The permissions associated with a secret determine the consequences of an exposure or attack. A database credential may provide access to customer records. A Kubernetes service account token may allow an attacker to retrieve additional Secret objects. A cloud credential may grant access to infrastructure outside Kubernetes.
The real risk extends across every system that trusts the exposed credential.
Real-world Kubernetes credential leaks expose the larger problem
Three recent GitGuardian investigations demonstrate how credentials can move through software delivery systems and expose connected infrastructure.
A Leaked Kubernetes credential opened access to private resources
GitGuardian researchers investigating publicly exposed Kubernetes credentials. They identified 44 active clusters accessible through leaked secrets; this was one research project, and we know many more are exposed every day. In the clusters they examined, four had more than 10 nodes, and one exceeded 200 nodes. A full 30% of the accessible clusters had been exposed for more than two years. The oldest valid leak dated back to 2021.
One case began when a service account token was embedded in a public Docker image which provided access to a K8 cluster. That cluster contained additional credentials. Ultimately, that key opened access to private container images and GitHub organizations.
The same research also identified over 2,000 container registry credentials with resolvable hostnames. Forty-six percent remained valid. Those credentials provided access to 309 private Docker Hub images and 730 private GitHub repositories.
A single leaked token created access to more secrets and additional systems.
K03 directly connects to excessive authorization and cluster-to-cloud lateral movement. A compromised credential can expose the next credential in the chain.
GhostAction targeted credentials inside trusted automation
The GhostAction supply chain campaign, which originally ran between Aug. 31 and Sept. 30, 2026, affected 772 public repositories and targeted 2,577 secret values. GitGuardian's researchers originally uncovered this attack. The attack targeted credentials used by automation, including cloud keys and container registry credentials.
Most workflow executions during this attack required approvals, which limited how bad this was and how many people were affected. However, a subsequent October wave affected another 346 repositories, with external researchers confirming successful exfiltration.
GhostAction targeted CI/CD infrastructure. The consequences can extend into Kubernetes because deployment pipelines frequently hold credentials granting access to registries and cloud services.
An attacker who steals those credentials may gain access to the same infrastructure used by legitimate deployment automation.
Securing Kubernetes therefore requires controls around the systems that build and deploy workloads.
The CISA repository leak exposed credentials and infrastructure context
In May 2026, GitGuardian researchers discovered a public GitHub repository named Private-CISA. While that might not sound that unusual, since CISA might stand for many different things, this repo contained 844 MB of plain-text passwords, AWS tokens, and Entra ID SAML certificates belonging to CISA, the US Cybersecurity and Infrastructure Security Agency. The exposed files included Kubernetes manifests, ArgoCD configurations, and Terraform infrastructure code.
Researchers tested many of these credentials and found them valid.
Researchers also found credentials and documentation describing internal infrastructure. The exposed information provided insight into how systems were configured and connected. Attackers could potentially use that context to identify valuable credentials and determine where those credentials might work.
The repository was taken offline following coordinated disclosure. But like with any incident, any exposed credentials still required investigation and appropriate remediation.
Repository scanning and credential lifecycle management help organizations address both the immediate exposure and its continuing consequences.
Reducing the blast radius of exposed Kubernetes credentials
Like with all Top 10 lists from OWASP, we have recommendations that provide a practical foundation for reducing risk, this time around Kubernetes credentials
Strict RBAC limits which identities can retrieve secrets. Namespace boundaries and network policies restrict access between workloads. Encryption at rest protects sensitive values stored in etcd.
Credential detection should also cover the software delivery process. Source repositories, CI/CD workflows, and container images all create opportunities for secrets to spread before applications reach production.
Security teams need to review credentials when they are exposed. While they might not be ultimately the "owner" of these credentials, they are the team responsible for dealing with the fallout of abuse of these credentials. They need to know validity, permissions, and actual usage to help determine the remediation priority. Rotation and revocation remove compromised access, while tighter permissions limit what future exposures can accomplish.
Workload identity federation provides an opportunity to reduce access persistence. GitGuardian's research found Kubernetes credentials that remained valid years after their original exposure. Supported Kubernetes workloads can use trusted identities to obtain temporary access to external services. Short-lived tokens reduce the useful lifetime of stolen credentials and the need to distribute permanent keys.
The long-term objective is to reduce the number of standing credentials while strengthening controls around those that remain.
How GitGuardian helps secure the Kubernetes credential layer
Kubernetes workloads depend on credentials that originate across the enterprise. Developer endpoints, source repositories, and CI/CD systems all participate in the credential lifecycle.
GitGuardian helps organizations secure this credential layer through three connected capabilities.
Detect exposed credentials and identify their context
GitGuardian detects exposed secrets across supported repositories and development environments. ggshield extends scanning into CI/CD workflows and container images.
When configured to integrate with Kubernetes clusters, the platform maps identity and infrastructure context, helping security teams understand where credentials are used and what access they provide.
Remediate exposed credentials and reduce excessive access
Finding a credential is just the first step; you need to actually remediate the findings. Security teams need to prioritize, investigate, and then take the right actions to reduce risk. This starts with establishing whether it remains valid and which services depend on it.
GitGuardian empowers investigation and prioritization for teams of any size. Part of this process includes using validity checks and surfacing contextual risk information. This helps teams coordinate rotation and reduce unnecessary permissions while protecting production availability.
Prevent new credential exposures
An ounce of prevention is worth a pound of remediation.
GitGuardian makes tools available for the developer and the local coding assistants to prevent secrets from being added or used throughout the software development process. ggshield, the GitGuardian CLI, supports developer-side checks and automated scanning within CI/CD pipelines. AI hooks provide additional checkpoints where agents interact with sensitive information.
Developer Endpoint Protection extends visibility into local machines where credentials tend to aggregate. This helps teams identify which secrets on a developer's laptop carry the most risk and plan remediation for plaintext secrets that haven't yet been abused or leaked publicly. This also gives you a clear prioritization path in cases of infostealer attacks affecting your organization.
Together, these capabilities help organizations reduce secrets sprawl across development and production environments.
Kubernetes security requires control over your credential layer
The OWASP Kubernetes Top 10 shows how exposed credentials can put entire environments at risk. A single leaked token can provide access to workloads, cloud infrastructure, and connected systems.
Securing Kubernetes and other production systems requires visibility and control across the entire credential layer. This stretches from developer laptops to repositories, CI/CD pipelines, and production workloads. Every system that can hold plaintext secrets is part of your credential layer.
GitGuardian helps you gain that control. Discover exposed credentials, prioritize remediation, and prevent new secrets from spreading across your development and production environments.
Get started with GitGuardian and take control of your credential layer today.
FAQ
What is the OWASP Kubernetes Top 10?
The OWASP Kubernetes Top 10 is a prioritized list of the most pressing risks affecting Kubernetes environments, based on real-world issues the community is reporting and working on. Its ten categories cover insecure workload configurations, overly permissive authorization, secrets management failures, missing network segmentation, exposed components, cluster to cloud lateral movement, broken authentication, and inadequate logging and monitoring.
Why does K03, Secrets Management Failures, deserve special attention?
Credentials very often provide access to systems far beyond the original cluster, and the permissions tied to a secret determine the consequences of an exposure. A database credential may expose customer records, a service account token may let an attacker retrieve more Secret objects, and a cloud credential may grant access to infrastructure outside Kubernetes. K03 also connects directly to excessive authorization and cluster to cloud lateral movement.
How do secrets get exposed in Kubernetes environments?
OWASP identifies six common paths: secrets baked into container images, sensitive values in ConfigMaps, secrets passed as environment variables, credentials committed to code repositories, excessive WATCH or LIST access to Secret objects, and secrets written to application logs. Each one can give an attacker usable credentials.
How do leaked credentials lead to Kubernetes cluster compromise?
GitGuardian researchers identified 44 active Kubernetes clusters accessible through leaked secrets, and 30% of them had been exposed for more than two years. In one case, a service account token embedded in a public Docker image opened a cluster that held more credentials, which in turn opened private container images and GitHub organizations. A single leaked token created access to more secrets and additional systems.
What is the GhostAction campaign and why does it matter for Kubernetes security?
GhostAction was a supply chain campaign, first uncovered by GitGuardian researchers, that affected 772 public repositories and targeted 2,577 secret values used by automation, including cloud keys and container registry credentials. A later wave affected another 346 repositories. The impact reaches Kubernetes because deployment pipelines frequently hold credentials that grant access to registries and cloud services.
How can teams reduce the blast radius of exposed Kubernetes credentials?
Use strict RBAC to limit which identities can retrieve secrets, apply namespace boundaries and network policies, and encrypt sensitive values in etcd at rest. Detect credentials across repositories, CI/CD workflows, and container images, then check validity, permissions, and actual usage to prioritize rotation and revocation. Workload identity federation and short-lived tokens reduce how long stolen credentials stay useful.
How does GitGuardian help secure the Kubernetes credential layer?
GitGuardian detects exposed secrets across supported repositories and development environments, and ggshield extends scanning into CI/CD workflows and container images. The platform maps identity and infrastructure context when integrated with Kubernetes clusters, and validity checks and contextual risk information help teams prioritize remediation. For prevention, ggshield, AI hooks, and Developer Endpoint Protection catch secrets before they spread.
Dwayne McDaniel
Guillaume Valadon
Thomas Segura
