TL;DR: Kubernetes does not ship secure by default. Privileged pods give attackers direct node access. Default service account tokens with overly permissive RBAC bindings provide API-level cluster control. Missing network policies allow unrestricted lateral movement between namespaces. Secrets stored in environment variables are readable by anyone with pod access. And exposed API servers or kubelet endpoints give unauthenticated attackers a foothold without needing application-level vulnerabilities at all. The path from a single compromised pod to cluster-admin is often three steps or fewer.
Kubernetes Misconfigurations by Severity
| Misconfiguration | Severity | Prevalence | Escalation Path |
|---|---|---|---|
| Privileged Pods | Critical | High | Pod to node root access via host filesystem mount |
| Overpermissive RBAC | Critical | Very High | Service account to cluster-admin via role binding abuse |
| Exposed API Server | Critical | Medium | Unauthenticated access to cluster management |
| Unauthenticated Kubelet API | Critical | Low-Medium | Remote code execution in any pod on the node |
| Exposed etcd | Critical | Low | Read all secrets, modify any cluster state |
| Missing Network Policies | High | Very High | Unrestricted lateral movement across namespaces |
| Secrets in Environment Vars | High | Very High | Credential theft from /proc or API queries |
| hostPath Volume Mounts | High | Medium | Read/write access to host filesystem from pod |
Privileged Pods: The Fastest Path to Node Compromise
A privileged pod (securityContext.privileged: true) runs with virtually no container isolation. The container process has full access to the host's /dev devices, can mount the host filesystem, operates in the host's PID namespace, and can load kernel modules. From an attacker's perspective, a privileged pod is functionally equivalent to root access on the node.
The escape technique is trivial: mount the host filesystem, write an SSH authorized key to the root user's home directory or drop a reverse shell cron job, and connect directly to the node. From the node, the attacker has access to the kubelet credentials, which typically have permissions to interact with the API server — enabling enumeration and further escalation across the cluster.
Privileged pods are more common than they should be because certain workloads appear to require them: monitoring agents, log collectors, network plugins, and storage drivers. In most cases, these workloads need specific Linux capabilities (NET_ADMIN, SYS_PTRACE) rather than full privileged mode. The principle of least privilege applies directly: grant the minimum set of capabilities required, not a blanket privileged flag.
Pod Security Standards
Kubernetes Pod Security Standards (replacing the deprecated PodSecurityPolicy) define three profiles: Privileged (unrestricted), Baseline (prevents known privilege escalations), and Restricted (heavily constrained). Enforcing the Baseline profile at the namespace level prevents privileged pods, host namespace sharing, and dangerous volume types. The Restricted profile adds requirements for non-root execution, read-only root filesystem, and dropped capabilities. Every production namespace should enforce at least the Baseline profile.
Service Account Token Abuse
Every pod in Kubernetes is assigned a service account, and by default, the service account's JWT token is automounted at /var/run/secrets/kubernetes.io/serviceaccount/token. This token authenticates requests to the Kubernetes API server. The permissions associated with this token depend on the RBAC bindings for the service account — and this is where the misconfiguration occurs.
In well-configured clusters, application pods use the default service account with no additional RBAC bindings, meaning the token has essentially no permissions. In misconfigured clusters, administrators bind broad roles to the default service account or create custom service accounts with excessive permissions: the ability to list secrets across namespaces, create new pods, modify deployments, or — in the worst case — cluster-admin privileges.
The attack from inside any pod with an overpermissive service account token is straightforward: read the token from the filesystem, use it to authenticate to the API server, enumerate permissions with kubectl auth can-i --list, and escalate based on what is available. Common escalation paths include listing secrets (to obtain database credentials, API keys, and other sensitive data), creating a new privileged pod (to escape to the node), or directly modifying existing deployments to inject malicious containers.
Remediation: Set automountServiceAccountToken: false on all pods that do not need to interact with the Kubernetes API. For pods that do, create dedicated service accounts with the minimum necessary RBAC permissions and audit bindings regularly.
RBAC Misconfigurations
Kubernetes RBAC controls who can do what within the cluster. The model uses Roles (namespace-scoped) and ClusterRoles (cluster-wide) bound to users, groups, or service accounts via RoleBindings and ClusterRoleBindings. The complexity of this system — combined with the pressure to get applications deployed quickly — produces misconfigurations that pentesters exploit reliably.
The most dangerous RBAC misconfigurations include wildcard permissions (verbs: ["*"] on resources: ["*"]), which grant unrestricted access to all resources in the cluster. ClusterRoleBindings that grant cluster-admin to service accounts used by application workloads. Permissions to create pods or deployments, which allow an attacker to launch a privileged pod and escape to the node. And permissions to escalate roles or bind ClusterRoles, which allow an attacker to grant themselves any permission.
Auditing RBAC Permissions
Use tools like kubectl-who-can, rakkess, or rbac-lookup to audit effective permissions across the cluster. Focus on service accounts in application namespaces — these are the tokens that attackers access when they compromise a pod. Any service account that can list secrets, create pods, or modify RBAC bindings across namespaces represents a cluster-admin-equivalent escalation path.
Exposed API Server and Kubelet
The Kubernetes API server is the control plane for the entire cluster. If it is exposed to the internet without authentication — or with anonymous authentication enabled — an attacker can enumerate and modify any resource in the cluster without credentials. While this is a critical misconfiguration, it is less common in managed Kubernetes services (EKS, GKE, AKS) where the API server is configured with authentication by default. Self-managed clusters are more frequently exposed.
The kubelet API on each node is a more commonly overlooked exposure. The kubelet runs on every worker node and exposes an API (typically on port 10250) that allows listing pods, executing commands in containers, and retrieving logs. If the kubelet API is exposed without authentication — either to the network or to the internet — an attacker can execute arbitrary commands in any pod running on that node. This is equivalent to full cluster compromise if the attacker can reach multiple node kubelets.
Remediation: Ensure the API server requires authentication (disable anonymous-auth), restrict access to the API server endpoint through network controls (VPN, private endpoint, IP allowlisting), and configure kubelet authentication and authorization (set --anonymous-auth=false and --authorization-mode=Webhook).
etcd Access and Secrets Extraction
etcd is the key-value store that backs the entire Kubernetes cluster state — including all Secrets objects. If an attacker gains read access to etcd, they can extract every secret in the cluster: database passwords, API keys, TLS certificates, and service account tokens. etcd access is effectively cluster-admin access with the additional ability to modify cluster state at the data layer, bypassing all RBAC controls.
etcd should never be exposed outside the control plane network. In managed Kubernetes services, this is handled by the cloud provider. In self-managed clusters, etcd must be configured with mTLS (mutual TLS) authentication, encrypted at rest, and restricted to the API server nodes only. Pentesters test for etcd exposure by scanning for port 2379 and attempting unauthenticated reads of the /v3/kv/range endpoint.
Network Policy Gaps
By default, Kubernetes imposes no network segmentation between pods. Every pod can communicate with every other pod across every namespace — a flat network that allows unrestricted lateral movement after initial compromise. This is the single most common Kubernetes security misconfiguration, and it transforms a single compromised pod into a launchpad for attacking every service in the cluster.
Network policies must be explicitly created to restrict traffic. A baseline policy that denies all ingress and egress by default, then selectively allows required communication paths, mirrors the principle of least privilege at the network layer. In practice, implementing comprehensive network policies requires understanding the full communication map of your applications — which services talk to which, on which ports, in which direction.
For a comprehensive assessment of your Kubernetes security posture — including RBAC audit, pod security evaluation, network policy review, and full attack chain testing from pod compromise to cluster escalation — schedule a Kubernetes security assessment with Lorikeet Security.
Harden Your Kubernetes Clusters
Lorikeet Security's Kubernetes penetration testing covers the full attack chain — from pod compromise to cluster-admin escalation. We test RBAC configurations, pod security contexts, network policies, secret management, and control plane exposure. Get a clear picture of your cluster's security posture.
