Kubernetes (K8s) has become the standard platform for running cloud-native applications. Enterprises now host payment systems, customer portals and AI workloads on clusters that change many times a day. The same speed that makes Kubernetes attractive also creates its central security problem.
Every new deployment introduces fresh configurations, container images, service accounts and open-source components that someone must verify before they reach production. Most security programs were designed for servers that changed a few times a quarter, so they struggle to keep pace with infrastructure that rebuilds itself on every commit.
This guide explains where Kubernetes risk sits across the cluster, the workload and the software supply chain. It also explains how security leaders can bring that risk under consistent governance.
What Is Kubernetes Security?
Kubernetes security is the set of controls that protect four areas: the cluster control plane, the nodes, the running workloads and the software supply chain that produces those workloads. It matters because a single weak setting in a shared cluster can expose every application that runs on it.
The State of Kubernetes Security 2024 report from Red Hat found that 67% of organizations delayed or slowed deployments because of security concerns. The same research reported that 89% of respondents faced at least one container or Kubernetes security incident in the previous year. It also found that 46% lost revenue or customers as a result. For a CISO, those numbers make Kubernetes a business continuity issue as well as an engineering topic. Kubernetes security also sits inside your wider multi-cloud security strategy, since most enterprises run managed clusters across more than one provider.
What Are The Biggest Kubernetes Cluster Security Risks?
The biggest cluster risks are as follows:
- Exposed control plane endpoints.
- Overly permissive role-based access control (RBAC).
- Unencrypted secrets.
- Outdated Kubernetes versions.
Attackers scan the internet for newly created clusters continuously and move fast once they find one. The Wiz Kubernetes Security Report 2025 found that new AKS clusters received their first attack attempt within 18 minutes of creation. New EKS clusters were targeted within 28 minutes. The same report found that only 54% of clusters run supported Kubernetes versions. That leaves many organizations exposed to vulnerabilities that already have published fixes.
In our cluster assessments, the most common finding is a cluster-admin binding that was never removed. It was usually granted “temporarily” to a CI/CD service account or a broad engineering group during a migration. Kubernetes Secrets present a related issue.
By default, they are only base64-encoded, and they need encryption at rest in etcd to provide real protection. A compromised identity with wide RBAC permissions can read those secrets, create privileged pods and move laterally across namespaces within minutes.
How Do Attackers Exploit Kubernetes Workloads And Containers?
Attackers exploit workloads in three main ways: breaking out of misconfigured containers, abusing exposed services and harvesting credentials from pods. A container gives an attacker a direct path from one compromised application to the underlying node if it does any of the following:
- Runs as root.
- Mounts the host filesystem.
- Uses the privileged flag.
The IngressNightmare vulnerabilities disclosed in March 2025 included CVE-2025-1974, which carries a CVSS score of 9.8. They showed how an exposed admission controller in ingress-nginx could allow unauthenticated remote code execution. That access extended to cluster-wide secrets.
Once attackers gain a foothold, cryptomining remains the most frequent payload. Ransomware groups and data theft campaigns are increasingly targeting cloud-native environments as well. Flat networking amplifies the damage, because Kubernetes allows all pods to communicate with each other unless network policies restrict that traffic. Runtime detection tools watch system calls, unexpected process execution and outbound connections. That visibility helps security teams spot these attacks while they are still contained.
What Are Kubernetes Supply Chain Risks And How Do They Spread?
Kubernetes supply chain risks are threats introduced through any of these components:
- Container images and base layers.
- Helm charts.
- Open-source dependencies.
- The CI/CD pipelines that build and deploy them.
These risks spread because one poisoned component can be pulled into hundreds of deployments automatically. A typical enterprise image inherits dozens of packages from public registries. Few teams track who maintains each one or how quickly it receives patches.
The pattern mirrors the broader software supply chain attack model, where attackers compromise a trusted upstream source instead of the final target. In Kubernetes, that can mean a typosquatted image on a public registry or a Helm chart with hardcoded credentials. It can also mean a build runner with access to production signing keys.
Effective controls work in three layers:
- SBOMs: Generate a software bill of materials (SBOM) for every image.
- Signing: Sign images with tools such as Sigstore Cosign.
- Admission policies: Reject unsigned or unscanned artifacts at deployment.
Teams that build these checks into a structured DevSecOps program catch supply chain issues during the build, where fixes cost far less than in production.
Which Kubernetes Security Best Practices Should Security Leaders Prioritize?
Security leaders should prioritize five areas:
- Identity control
- Workload hardening
- Network segmentation
- Supply chain verification
- Continuous runtime monitoring
Together, these five areas address most of the attack paths seen in real Kubernetes incidents. The official Kubernetes Security Checklist offers a useful baseline. The CIS Kubernetes Benchmark adds testable configuration controls for audits.
A practical starting sequence looks like this:
- Restrict access: Apply least-privilege RBAC, remove standing cluster-admin bindings and integrate cluster authentication with your enterprise identity provider.
- Harden workloads: Enforce the “restricted” profile of Pod Security Admission so that containers cannot run as root or request privileged access.
- Segment traffic: Apply default-deny network policies and allow only the pod-to-pod communication each application needs.
- Verify artifacts: Scan images in the pipeline, sign them and block unsigned images at admission.
- Monitor runtime: Send Kubernetes audit logs and runtime alerts to your SIEM so that analysts can correlate cluster events with wider threat activity.
Independent validation completes the cycle and confirms that these controls hold under pressure. A Kubernetes-focused cloud security assessment reviews configuration drift. Advanced penetration testing shows whether an attacker can move from a single compromised pod to the control plane.
How Does Kubernetes Security Support PCI DSS, SOC 2 And ISO 27001 Compliance?
Kubernetes security supports compliance by producing the evidence that auditors expect under PCI DSS, SOC 2 and ISO 27001. That evidence covers access controls, segmentation, change records and monitoring. Each framework draws on different parts of it:
- PCI DSS: Version 4.0.1 requires organizations to define cardholder data environment boundaries. In a shared cluster, namespaces and network policies must isolate payment workloads from everything else.
- SOC 2: Auditors look for evidence of logical access reviews and change management. RBAC reviews and signed deployments provide that evidence.
- ISO 27001: Annex A controls on secure configuration and logging map directly to cluster hardening and audit log retention.
The challenge is that ephemeral pods make point-in-time evidence unreliable. Governance teams get better results when they collect configuration and policy data continuously. The evidence then reflects how the cluster behaved throughout the audit period.
Who Is Responsible For Kubernetes Security In A Shared Responsibility Model?
Responsibility for Kubernetes security is shared between three groups: the cloud provider, the platform team and the application teams. Managed services such as EKS, AKS and GKE secure the control plane infrastructure. The customer remains accountable for RBAC, workload configuration, network policies, images and data. Platform engineers usually own cluster guardrails, and application teams own the contents of their containers.
Problems appear when each group assumes another one covers a gap. A clear RACI model removes that ambiguity and gives auditors a defensible ownership record. The CISO should approve that model, and teams should review it during every major platform change.
| Secure your clusters, workloads and software supply chain with confidence by booking a Kubernetes security assessment with Ampcus Cyber. |
People Also Ask
Are Kubernetes Secrets encrypted by default?
No, Kubernetes Secrets are only base64-encoded by default, which is easy to reverse. Organizations should turn on encryption at rest for etcd, or use an external secrets manager, to protect credentials properly.
What replaced Pod Security Policy in Kubernetes?
Pod Security Admission replaced Pod Security Policy, which was removed in Kubernetes version 1.25. Pod Security Admission applies three built-in profiles: privileged, baseline and restricted. Teams apply these profiles at the namespace level.
Is managed Kubernetes like EKS, AKS or GKE secure by default?
Managed Kubernetes secures the control plane infrastructure, but it does not secure your workloads by default. Customers still need to configure RBAC, network policies, image controls and runtime monitoring themselves.
What is the difference between container security and Kubernetes security?
Container security focuses on the image and the running container process. Kubernetes security also covers the control plane, identity, networking, policy enforcement and the orchestration layer that manages those containers.
How often should an enterprise assess its Kubernetes clusters?
Most enterprises should run continuous configuration scanning and a formal assessment at least once a year. They should also add an assessment after any major platform change, a version upgrade or a new compliance scope.
Enjoyed reading this blog? Stay updated with our latest exclusive content by following us on Twitter and LinkedIn.
