 is Kubernetes's authorisation framework. Misconfigured RBAC is the most common path to privilege escalation within a cluster.){kind=link}
Kubernetes has become the default infrastructure platform for containerised workloads. It offers powerful orchestration, scaling, and deployment capabilities but it also introduces a large, complex attack surface that many DevOps teams have not fully mapped. Kubernetes security misconfigurations have contributed to some notable cloud security incidents, and the pattern of findings is consistent enough that defenders can work from a well-understood list.
The challenge is that Kubernetes was designed for operational flexibility, and security controls often require explicitly reducing that flexibility. Default configurations in self-managed clusters are not secure. Managed Kubernetes services like EKS, AKS, and GKE apply some defaults better than self-hosted alternatives, but they still require significant configuration to reach a defensible posture.
RBAC Misconfigurations
Role-Based Access Control (RBAC) is Kubernetes’s authorisation framework. Misconfigured RBAC is the most common path to privilege escalation within a cluster. The default service account in many namespaces has access it does not need. Roles created with wildcard permissions (* on resources or verbs) grant broad access to anyone who obtains a pod with that binding.
A compromised pod that has the cluster-admin role bound to its service account gives an attacker full control of the cluster. This is not a theoretical scenario workloads deployed with over-privileged service accounts are a consistent finding in Kubernetes assessments.
The Kubernetes API Server
The API server is the control plane of the cluster. Exposing it to the internet, or failing to restrict access within the cluster, creates direct exploitation paths. Unauthenticated access to the API server (which is possible in some misconfigured clusters) gives an attacker full cluster control without needing to compromise a workload first.
etcd, the key-value store that backs Kubernetes, contains secrets, configurations, and cluster state. If etcd is accessible without authentication or if its backup files are stored insecurely an attacker can extract all cluster secrets directly.
Container Escape and Lateral Movement
Containers that run as root, with privileged mode enabled, or with host path mounts are all potential container escape vectors. An attacker who compromises a container running with these configurations may be able to break out to the underlying node and then move laterally to other nodes or back into the cluster control plane.
Web application penetration testing of applications running in Kubernetes should include testing for vulnerabilities that could lead to container compromise, which then becomes the starting point for cluster-level exploitation. The application and the infrastructure are connected attack surfaces.
Secrets Management
Kubernetes Secrets are base64-encoded by default not encrypted. An attacker with access to etcd, or with the ability to list secrets in a namespace, can recover credentials, API keys, and certificates that may allow further movement within the environment.
Integrating external secrets management tools HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault and ensuring encryption at rest for etcd are both important steps toward more secure secrets handling.
Continuous Security in Kubernetes
Vulnerability scanning services for Kubernetes workloads include image scanning checking container images for known vulnerable packages before they are deployed and cluster configuration scanning, which checks RBAC, network policies, pod security settings, and API server exposure against CIS Kubernetes Benchmarks.
DevOps teams that integrate security tooling into their CI/CD pipelines catch problems before they reach production. Policy-as-code tools like OPA Gatekeeper enforce security standards on admission rejecting deployments that violate defined policies before the pod ever runs. Building security into the pipeline is faster, cheaper, and more effective than finding issues in production.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
“Kubernetes security is an area where good intentions and bad defaults collide regularly. RBAC misconfiguration and over-privileged service accounts are the findings that concern us most the blast radius when those are exploited can extend across the entire cluster.”