Exposed Kubernetes API Server (TCP 6443 / 8443 / 10250)
detect, harden, and verify closure

Public API endpoint on a managed cluster

An EKS, AKS, or GKE cluster is created with the public endpoint enabled and the source IP allowlist set to 0.0.0.0/0 during a console click-through, a CDK or Terraform default, a debugging session, or a vendor handoff. The flag persists across cluster upgrades, autoscaler events, and account migrations. The control plane itself is hardened by the hyperscaler, but the listener is still reachable from the public internet and accepts kubectl from anywhere on earth. RBAC misconfiguration on the same cluster turns a reachable listener into a cluster takeover.

Self-managed control plane on cloud VMs

A kops, kubeadm, k3s, RKE, or vanilla kube-apiserver deployment on EC2, Compute Engine, Azure VM, or DigitalOcean droplets binds the apiserver to 0.0.0.0:6443 with --anonymous-auth=true and accepts public traffic. The deployment also exposes etcd on 2379 for cluster-internal traffic without TLS client-certificate enforcement, and the kubelet on 10250 with --authorization-mode=AlwaysAllow because the operator copied a quick-start guide. The plaintext bind survives across image rebuilds, autoscaling events, and node refreshes long after the original convenience reason is forgotten.

Over-permissive RBAC for anonymous users

A ClusterRoleBinding grants the system:anonymous or system:unauthenticated user a role that lets it list pods, list nodes, list namespaces, or read secrets. The binding is often left behind by an early debugging session, a stale tutorial, a Helm chart that ships an anonymous read for service discovery, an admission webhook that needs an anonymous probe path, or a monitoring agent that wanted unauthenticated cluster reads during prototyping. A reachable apiserver plus a permissive anonymous binding equals the same outcome as a fully unauthenticated apiserver.

Kubelet anonymous-auth and AlwaysAllow

The kubelet on every node ships with --anonymous-auth=true and --authorization-mode=AlwaysAllow in legacy distributions, in self-managed deployments, in development clusters that were never retuned, in k3s installs whose flag defaults differ from upstream, and in IoT and edge deployments that prioritise zero-touch onboarding. The kubelet exposes /pods, /containerLogs, /exec, /run, /portForward, and /metrics on 10250 without an authentication or authorisation check. A reachable kubelet is a node takeover before the apiserver even enters the discussion.

Cloud security group rule too broad

An AWS security group, Azure NSG, GCP firewall rule, or DigitalOcean rule opens TCP 6443, 8443, 10250, 2379, or 2380 to 0.0.0.0/0 during a Terraform run, a debug session, a vendor handoff, or a recovery exercise. The rule is never narrowed, and a public Kubernetes control plane persists across image rebuilds, autoscaling events, and account migrations. Public-cloud attacker tooling continuously sweeps cloud netblocks for the pattern.

etcd reachable without client certificates

A self-managed etcd cluster on TCP 2379 (client) and 2380 (peer) is configured without --client-cert-auth=true and --peer-client-cert-auth=true, or with the TLS material missing entirely. The peer port that nodes use for replication is reachable from outside the cluster network, and the client port that the apiserver uses is reachable from the same broad range. A caller with network access reads every cluster object including every Secret in plaintext and writes new objects that the apiserver will reconcile into cluster state.

Automated detection

• SecPortal's external scanner port-scan module probes TCP 6443, 8443, 10250, 2379, and 2380 across every verified domain and host in scope. Port 6443 is registered in the scanner port catalogue as kubernetes-api, and the tech-fingerprint module identifies kubernetes through banner and port signals on 6443 and 10250. Every responding listener that is reachable from the public internet raises a critical-severity finding under the rule that the Kubernetes control plane should never be addressable from 0.0.0.0/0.
• Continuous monitoring re-runs the external scan on a schedule, so a security-group edit, a Terraform apply, a managed-cluster public-endpoint flag flip, an autoscaler event, or a recovered host that reopens 6443 or 10250 reopens the finding rather than leaving the regression invisible until the next audit cycle.
• Bulk import accepts Nessus, Burp, and CSV output from network-tier scanners and from Shodan and Censys exports that already list exposed Kubernetes API servers and kubelets, so the catalogue stays centralised even when a third-party tool is the original discovery source.

Manual verification

• Use nmap -p 6443,8443,10250,10255,2379,2380 with service detection (-sV) and the http-headers and ssl-cert scripts against the external range to confirm the listener, the TLS certificate subject, and whether the response advertises Kubernetes on the HTTP banner.
• Issue curl -sk https://<host>:6443/version against each reachable apiserver. A populated JSON response with major, minor, gitVersion, gitCommit, buildDate, goVersion, and platform is proof of a reachable Kubernetes control plane. Issue curl -sk https://<host>:6443/api/v1/pods to test whether system:anonymous can list pods. A populated PodList rather than a 401 or 403 is proof of an unauthenticated or weakly authenticated apiserver.
• Issue curl -sk https://<host>:10250/pods against each reachable kubelet. A populated PodList without an Authorization header is proof of --anonymous-auth=true and --authorization-mode=AlwaysAllow. The same probe at /metrics returns node-level telemetry on a permissive kubelet.
• For inside-the-cluster verification, run kubectl auth can-i --list --as=system:anonymous and kubectl auth can-i --list --as=system:unauthenticated to enumerate every permission the anonymous and unauthenticated users hold across the cluster. Audit ClusterRoleBindings whose subjects include system:anonymous, system:unauthenticated, system:authenticated, or empty subject lists. Cross-reference Shodan and Censys for the organisation's netblocks and known hostnames to see whether external observatories already list exposed control planes or kubelets.

Surface every reachable apiserver and kubelet on one finding record

External scanning and bulk import land every exposed-Kubernetes-API detection on the findings management record with CVSS, the discovered host, the captured /version response, the apiserver build, the platform, the scan timestamp, and the named owner so the catalogue is a single source of truth rather than a Shodan tab, a spreadsheet, and a Slack thread.

Inspect cluster posture through authenticated scans

Where the team has authorisation and a kubeconfig with read-only access, the authenticated scanning path pairs external-listener evidence with the per-cluster hardening record. Credentials for authenticated runs live in encrypted credential storage scoped to a verified domain so the same kubeconfig is not copied across spreadsheets, chat threads, and pull-request bodies.

Run remediation as a tracked workflow

Each finding flows through the remediation tracking workflow with severity, target close date, named owner, and the agreed compensating control (for example, an inbound source allowlist while a private bastion is provisioned, a temporary firewall rule while the master authorized networks list is narrowed, or a Kyverno enforce-mode rollout while audit-mode coverage is validated). Permanent exceptions enter the eight-field exception register with a named approver, a rationale, an effective period, and a renewal cadence.

Verify the fix with retest

Once the firewall rule, the security-group edit, the apiserver flag change, the kubelet config update, the managed-cluster endpoint flip, or the etcd TLS rollout completes, the retesting workflow re-runs the external scan, confirms the listener is gone or that the responding service now refuses anonymous requests on a private interface, and stamps the closure with timestamped evidence rather than a verbal sign-off in a stand-up.

Catch regressions through continuous monitoring

Scheduled continuous monitoring re-scans of verified domains reopen the finding if a Kubernetes control plane returns to the public internet, if a new self-managed cluster spins up with the apiserver bound to 0.0.0.0:6443, or if a new cloud account joins the estate with an open kubelet port. A Terraform apply, a managed-cluster public-endpoint flag flip, an autoscaler event, or a recovered backup image does not silently reintroduce the exposure.

Pair the apiserver finding with the node-level exposure

A permissive kube-apiserver, a permissive kubelet, an unauthenticated etcd, and a mounted Docker socket or runtime socket on a node are the same root-equivalence pattern at different layers. Treating them as one finding family on the workspace record, with the cluster as the affected asset and the listener type or RBAC binding as the evidence, keeps the queue ordered against real residual risk rather than reading three unrelated queues. The same record flows through container image vulnerability remediation and Kubernetes security finding remediation where appropriate.

Carry the audit trail through closure

The activity log records who opened, scoped, remediated, and verified each exposed-Kubernetes-API finding, so the next ISO 27001, SOC 2, PCI DSS, NIST CSF 2.0, or cyber-insurance review reads the operating evidence from the record rather than from reconstructed memory, archived ticket exports, or screenshots taken weeks after the fact. The compliance tracking crosswalk maps each finding to the relevant control catalogue so audit fieldwork reads from the same record.

Communicate posture in leadership language

When cluster exposure sits inside a broader programme review, the Claude-drafted AI report composes a leadership-ready narrative from the open and closed findings, the remediation cadence, and the linked compliance evidence. The same record drives security leadership reporting without rebuilding the slide deck by hand each quarter.

Managed clusters with public endpoints

EKS, AKS, GKE, DOKS, Linode Kubernetes Engine, and other managed control planes are the most common modern exposure. The hyperscaler hardens the control-plane binaries, but the public-endpoint flag and the source IP allowlist remain operator-controlled. Set the endpoint to private, use a managed bastion service or zero-trust access broker for human operators, and scope master authorized networks to a small allowlist tracked as configuration evidence on the finding record.

Self-managed control planes on cloud VMs

kops, kubeadm, k3s, RKE, RKE2, Talos, and home-grown apiserver deployments on EC2, Compute Engine, Azure VM, and DigitalOcean droplet stacks make up the bulk of historic exposure events. Replace standing 0.0.0.0/0 security-group rules with private subnets, security-group source restrictions, and managed bastion access for human operators. Move long-lived production workloads onto a managed orchestrator where the network boundary is built in and the per-node listener is not directly addressable.

Kubelet and read-only-port exposure on every node

A reachable kubelet on TCP 10250 with --anonymous-auth=true or --authorization-mode=AlwaysAllow bypasses the apiserver entirely and exposes /pods, /containerLogs, /exec, /run, and /metrics on every node. A reachable read-only port on TCP 10255 (deprecated since Kubernetes 1.10 but still set on long-lived nodes) exposes the same telemetry without any authentication. Set --anonymous-auth=false, --authorization-mode=Webhook, and --read-only-port=0 on every kubelet, and verify the values per node rather than per cluster.

Edge, IoT, and legacy clusters

Long-lived virtual machines, vendor-distributed appliances, customer-managed instances at acquired companies, k3s installs on edge devices and IoT gateways, and home-grown installs run a Kubernetes release several versions behind the upstream support window and frequently inherit the legacy plaintext-bind, anonymous-auth defaults. Track these clusters on the finding record with the kube-apiserver version, the kubelet version, the maintainer contact, and the upgrade path. Where the cluster cannot be upgraded immediately, isolate it behind a managed network access boundary and document the residual risk decision in the exception register.