What it means for teams

OWASP notes that popular managed distributions expose the API server to the internet with no source address limit by default. A credential taken from a laptop or a public repository then works from anywhere. Access to etcd is equivalent to root in the cluster, and a kubelet that accepts anonymous requests can be driven directly.

How to prevent it

  • Make the API endpoint private, or restrict it to known source address ranges, on every cluster.
  • Keep the kubelet port (10250) reachable only from the API server and the hosts that need it, and run the kubelet with --anonymous-auth=false and --authorization-mode=Webhook.
  • Keep etcd on the control-plane network, behind a firewall, and require client certificates (--client-cert-auth=true) so only the API servers can connect.
  • Scan your own address ranges for exposed Kubernetes endpoints, because the /version endpoint and TLS certificate names identify them.

Guides on this site

Also covers this · Guide

Harden managed Kubernetes on EKS, AKS and GKE

Know what your provider secures and what you still own, then lock down API access, cloud identity, nodes, pod privileges and admission with settings that are generally available in Kubernetes 1.37, checked against the CIS and NSA/CISA baselines.

Gaps on this site

One section of the managed Kubernetes guide restricts who can reach the API server on EKS, AKS and GKE. No guide here covers exposed kubelets or etcd, or clusters you run yourself, and none has an exercise that finds exposed components.

References

  1. K06:2025 Overly Exposed Kubernetes Components (OWASP)
  2. Kubernetes documentation: Kubelet authentication/authorization
  3. Kubernetes documentation: Operating etcd clusters for Kubernetes (Securing etcd clusters)

List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.