Top 10 Kubernetes Security Risks

Most Kubernetes compromises do not need a zero-day: they use a permission, a pod setting or an exposed endpoint that the cluster accepted because nothing told it not to. Kubernetes defaults favour getting workloads running, so audit logging is off, Secrets sit unencrypted in etcd and pods can talk to every other pod until someone changes it. This list ranks ten Kubernetes security risks by our judgement of likelihood and impact, mapped to the OWASP Kubernetes Top 10 (2025 edition) and to ATT&CK v20 techniques, with the first fix and how to find each problem in your own clusters. It closes with the common Kubernetes misconfigurations to hunt for and a simple way to score cluster risk. It is for platform engineers, cluster administrators and cloud security teams running self-managed or managed Kubernetes.

The Top 10 at a glance

1. Overly permissive RBAC and authorisation
2. Insecure workload configurations
3. Exposed API server, kubelet, etcd and dashboards
4. Secrets management failures
5. Service account tokens and broken authentication
6. Cluster-to-cloud lateral movement
7. No network segmentation inside the cluster
8. No cluster-level policy enforcement
9. Vulnerable components and an untrusted image supply chain
10. Inadequate audit logging and runtime detection

1. Overly permissive RBAC and authorisation

The risk: cluster-admin bound to CI pipelines, operators and humans "for now", wildcard verbs and resources in Roles, and subtle grants that amount to admin. The Kubernetes RBAC Good Practices list the escalation paths: escalate, bind and impersonate verbs, create on serviceaccounts/token, approval of certificate signing requests, control of admission webhooks, patch on Namespaces (which can relabel away Pod Security), and nodes/proxy, which reaches the kubelet API and "bypasses audit logging and admission control". Attackers who gain any of these grant themselves more (T1098.006 Additional Container Cluster Roles).

Why it matters: RBAC is the cluster's only authorisation boundary. Membership of system:masters "bypasses all RBAC rights checks", and removing bindings cannot revoke it.

The fix: list every ClusterRoleBinding to cluster-admin and every Role with *, replace them with namespaced Roles of named verbs and resources, keep system:masters as a break-glass mechanism only, as the Kubernetes security checklist advises, and review access at least every 24 months (the checklist's ceiling; quarterly is better for admin rights). Treat create on pods or deployments as access to every Secret and service account in that namespace. See the Kubernetes Security Guide.

2. Insecure workload configurations

The risk: containers running as root, with privileged: true, host namespaces (hostNetwork, hostPID, hostIPC), hostPath volumes, added capabilities or writable root filesystems (T1610 Deploy Container, T1611 Escape to Host).

Why it matters: each of these weakens or removes the boundary between the container and the node, and a node holds the kubelet's credentials, other pods' Secrets and often a cloud role.

The fix: apply the Pod Security Standards with Pod Security Admission namespace labels. Baseline "prevents known privilege escalations"; Restricted follows "current Pod hardening best practices" and requires runAsNonRoot: true, allowPrivilegeEscalation: false, capabilities.drop including ALL (only NET_BIND_SERVICE may be added) and a RuntimeDefault or Localhost seccomp profile. NSA and CISA add: "Where possible, run containers with immutable file systems." See the Container Security Guide.

3. Exposed API server, kubelet, etcd and dashboards

The risk: API servers on public endpoints, kubelets (port 10250) accepting anonymous requests, etcd (ports 2379 and 2380) reachable from workloads, and web dashboards or ML consoles published without authentication (T1190 Exploit Public-Facing Application, T1133 External Remote Services).

Why it matters: the Tesla Kubernetes cryptojacking began at an open console that exposed AWS credentials, and the Kubeflow cryptomining attacks used exposed dashboards. NSA and CISA note that "In Kubernetes 1.6 and newer, anonymous requests are enabled by default", and that write access to etcd can give "root access to the entire cluster".

The fix: meet the checklist item "The Kubernetes API, kubelet API and etcd are not exposed publicly on Internet": private or IP-restricted control plane endpoints on managed services, --anonymous-auth=false on the API server and kubelet, kubelet authorisation in Webhook mode, etcd reachable only from the API server with mutual TLS, and no dashboards exposed through LoadBalancer services or ingress without SSO in front.

4. Secrets management failures

The risk: Secrets stored unencrypted in etcd, broad list and watch on Secrets, credentials in ConfigMaps, environment variables and committed manifests (T1552.007 Container API).

Why it matters: NSA and CISA state that "By default, Secrets are stored as unencrypted base64-encoded strings". The Kubernetes docs warn that "Granting list access to Secrets implicitly lets the subject fetch the contents of the Secrets", and that in a shared manifest "The secret is available to everyone who can read the manifest". The exposed Kubernetes Secrets case involving SAP shows how far one leaked key can reach.

The fix: configure encryption at rest for the Secret API with a KMS provider, give get on named Secrets only to the workloads that need them, keep list and watch for system components, never put credentials in ConfigMaps, and keep long-lived credentials in an external store delivered through the Secrets Store CSI Driver. Scan Git repositories and images for kubeconfig files and tokens. See the Kubernetes NHI Security Guide.

5. Service account tokens and broken authentication

The risk: every pod gets a service account token mounted by default, legacy non-expiring token Secrets survive from older clusters, users authenticate with static client certificates or shared kubeconfigs, and CI systems hold long-lived cluster credentials (T1528 Steal Application Access Token, T1078 Valid Accounts).

Why it matters: a mounted token turns any code execution in a pod into an authenticated API client. Client certificates cannot be revoked in Kubernetes short of rotating the issuing CA, so a leaked admin certificate stays valid until it expires.

The fix: set automountServiceAccountToken: false on service accounts and pods that do not call the API (NSA and CISA give the same instruction), use bound, projected tokens rather than token Secrets (checklist: "Bound service account token volume is in-use instead of non-expiring tokens"), delete leftover token Secrets, authenticate humans through OIDC to your identity provider with MFA, and replace CI kubeconfigs with short-lived, federated credentials. See the CI/CD Pipeline Identity Security Guide.

6. Cluster-to-cloud lateral movement

The risk: pods reach the cloud instance metadata service and take the node's IAM role, or workloads share one broad cloud identity, so a single compromised container reaches storage, databases and other accounts (T1552.005 Cloud Instance Metadata API). OWASP added this as K08 in its 2025 list.

Why it matters: node roles in managed Kubernetes typically hold registry, network and storage permissions for every pod on the node. The cluster becomes the entry point to the cloud estate, as the Tesla case showed with AWS credentials.

The fix: filter workload access to the metadata API (a checklist item), for example IMDSv2 with a hop limit of one on Amazon EKS nodes; give each workload its own cloud identity through EKS Pod Identity or IAM roles for service accounts, Workload Identity Federation for GKE, or Microsoft Entra Workload ID on AKS; and keep node roles to what the node itself needs. See the Cloud Workload Identity Guide.

7. No network segmentation inside the cluster

The risk: Kubernetes allows all pod-to-pod traffic by default, and NetworkPolicy objects do nothing unless the CNI plugin enforces them. Attackers scan and reach databases, internal APIs and other tenants (T1046 Network Service Discovery, T1613 Container and Resource Discovery).

Why it matters: a flat cluster turns one compromised web pod into access to every service, including the metadata endpoint and the control plane.

The fix: confirm the CNI enforces policy, then follow the NSA and CISA advice to "Use a default policy to deny all ingress and egress traffic" in each namespace and allow named flows. Restrict LoadBalancer and ExternalIPs, and isolate sensitive workloads on dedicated nodes or sandboxed runtimes. See the Network Segmentation Guide.

8. No cluster-level policy enforcement

The risk: standards exist in a wiki but nothing rejects a non-compliant manifest at admission, exceptions are granted by relabelling namespaces, and each team's cluster drifts differently.

Why it matters: without admission control every other fix on this list is optional. The Kubernetes checklist expects "An appropriate selection of admission controllers is enabled" and Pod Security "enforced" for all namespaces.

The fix: run Pod Security Admission plus a policy engine or ValidatingAdmissionPolicy for rules Pod Security does not cover (allowed registries, required labels, no latest tags, resource limits). Start in audit and warn mode, fix what it reports, then switch to enforce; roll back by returning a namespace to warn, not by deleting the policy. Restrict who can patch namespace labels and webhook configurations.

9. Vulnerable components and an untrusted image supply chain

The risk: clusters running unsupported Kubernetes versions, unpatched add-ons and ingress controllers, and images pulled by mutable tag from public registries, some carrying malware or embedded secrets (T1525 Implant Internal Image, T1612 Build Image on Host, T1068 Exploitation for Privilege Escalation).

Why it matters: the Kubernetes project maintains release branches for only "the most recent three minor releases", each with "approximately 1 year of patch support". The Docker Hub secrets leak found cloud, CI and AI keys in 10,456 public images.

The fix: upgrade on a schedule that never leaves a cluster outside support, patch add-ons and CNI with the same priority, reference images by sha256 digest or verify signatures at admission, scan images in the pipeline and the registry, and allow pulls only from approved registries. See the Container Image Security Guide and the Software Supply Chain Security Guide.

10. Inadequate audit logging and runtime detection

The risk: NSA and CISA note that Kubernetes "built-in audit logging capabilities perform no logging by default". Without audit logs and runtime telemetry, exec into pods, new privileged workloads, cryptominers and attempts to disable monitoring go unseen (T1609 Container Administration Command, T1496 Resource Hijacking, T1685 Disable or Modify Tools).

Why it matters: cryptomining in the Tesla and Kubeflow cases was the visible symptom; the access came earlier and was never logged.

The fix: enable an audit policy (Metadata level for most resources and always for Secrets, so values never reach the log; RequestResponse for RBAC changes), protect the logs "from general access" and ship them off-cluster. Alert on: pods/exec and pods/attach, new ClusterRoleBindings, Secret list by non-system identities, privileged or hostPath pods, anonymous requests, token requests for other service accounts, and DaemonSets created outside the pipeline. Add runtime detection on nodes for shell spawns, unexpected outbound connections and miners.

Mapping to OWASP

The OWASP Kubernetes Top 10 project site now presents a 2025 list alongside the 2022 edition. The 2025 list drops the separate supply chain entry and adds Overly Exposed Kubernetes Components (K06) and Cluster To Cloud Lateral Movement (K08). We keep supply chain inside risk 9 because image provenance still causes incidents.

Where to start

If you can do only three things this quarter: take the API server, kubelet and dashboards off the internet and turn off anonymous access (risk 3), turn on audit logging and ship it off-cluster (risk 10), and apply Pod Security Baseline in enforce mode everywhere except system namespaces (risk 2). Next, remove cluster-admin from pipelines and people (risk 1) and block pod access to the metadata API (risk 6).

Common Kubernetes misconfigurations to hunt for

For Kubernetes risk scoring, score each cluster on exposure (public endpoint, internet-facing ingress), privilege (cluster-admin bindings, privileged pods, node cloud role scope), data (Secrets and regulated data held) and visibility (audit and runtime coverage), weight exposure and privilege highest, and fix the highest-scoring cluster first. Track five numbers monthly: namespaces enforcing Restricted or Baseline (target all non-system namespaces), cluster-admin bindings outside break-glass (target zero), pods with auto-mounted tokens that never call the API, clusters within the supported version window (target all), and clusters with audit logs off-cluster (target all).

Standards and references

• OWASP: Kubernetes Top 10
• NSA and CISA: Kubernetes Hardening Guide v1.2
• Kubernetes: Pod Security Standards
• Kubernetes: Role Based Access Control Good Practices
• Kubernetes: Good practices for Kubernetes Secrets
• Kubernetes: Security Checklist
• MITRE ATT&CK: Containers Matrix

Related NHI Mgmt Group resources: Kubernetes Security Guide · Container Security Guide · Container Image Security Guide · Kubernetes NHI Security Guide · Top 10 Cloud Security Risks