Port 6443 – Kubernetes API Server (kube-apiserver)

Port 6443 is the canonical HTTPS endpoint of the Kubernetes API server (kube-apiserver) — the single front door to a Kubernetes cluster’s control plane. Every kubectl command, every controller, every kubelet, and every CI pipeline that touches the cluster speaks to the REST API served here over TLS. Because the API server is the one component that reads and writes all cluster state — Pods, Secrets, RBAC bindings, everything in etcd — an open port 6443 is one of the highest-value targets on any host that runs it. Some distributions serve the same API on 8443 (k3s, some managed setups) or 443 (behind a load balancer), but 6443 is the upstream default. The dominant risk here is rarely a single exploit: it is a misconfiguration — anonymous access or over-permissive RBAC — that hands an attacker the keys to the whole cluster.

Why It’s Open

Port 6443 is open because the cluster needs it open — it is not an optional service. The API server is the hub every other component talks to:

• kubectl and operators connect to 6443 to create, read, update, and delete every object in the cluster.
• kubelets, controllers, and the scheduler authenticate to the API server to reconcile desired state.
• CI/CD, GitOps agents, and cloud integrations hold service-account tokens or kubeconfigs that authenticate against 6443.

On a properly built cluster the port is reachable only from the control-plane subnet and trusted operator networks, and every request is authenticated (client cert, bearer token, or OIDC) and authorized by RBAC. The problem is how often that isn’t the case: managed-cluster API endpoints get published to 0.0.0.0, self-hosted control planes sit on a public cloud VM with a wide-open security group, and RBAC or the anonymous-auth setting is loosened “just to get it working.” When 6443 answers from the internet, the only thing between an attacker and cluster-admin is the authentication and authorization config — and that is exactly what tends to be wrong.

Common Risks

• Anonymous / unauthenticated API access. If kube-apiserver runs with --anonymous-auth=true (still the default) and a ClusterRoleBinding grants rights to system:anonymous or the system:unauthenticated group, an unauthenticated attacker inherits those rights. A single careless ClusterRoleBinding to cluster-admin (a real, repeated mistake) turns 6443 into a wide-open cluster.
• Read every Secret in the cluster. With list access to Secrets, an attacker pulls cloud-provider keys, database passwords, TLS private keys, and service-account tokens straight out of the API — often the fastest path off the cluster and into the cloud account.
• Create privileged Pods → node/host takeover. Create rights on Pods let an attacker schedule a privileged: true or hostPath: / Pod that mounts the node’s filesystem, reads its kubelet credentials, and escapes to the underlying host — pivoting from “API access” to “root on every node.”
• Exec into running Pods. pods/exec rights give an interactive shell inside existing workloads, exposing in-memory secrets and lateral movement paths.
• Unauthenticated fingerprinting endpoints. /version, /api, /apis, /healthz, and /openapi/v2 frequently answer without credentials, disclosing the exact Kubernetes version so an attacker can match it to a known CVE.
• Leaked kubeconfigs and service-account tokens. A kubeconfig committed to Git, baked into an image, or left on a jump box — or an over-scoped service-account token exfiltrated from a Pod — is a valid credential for 6443 that needs no exploit at all.
• Adjacent control-plane targets. The API server rarely sits alone: the kubelet API on 10250 and etcd on 2379 are the neighbouring control-plane services, each a full-cluster compromise in its own right if reachable, and worth scanning alongside 6443.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

The workflow on 6443 is: confirm it’s a Kubernetes API server, fingerprint the version, then test what your current identity (including “anonymous”) is actually allowed to do.

Confirm the port and detect the service

nmap -sV -p 6443 <target>

Fingerprint the API server without credentials

curl -k https://<target>:6443/version
curl -k https://<target>:6443/api
curl -k https://<target>:6443/healthz
curl -k https://<target>:6443/openapi/v2

/version returning JSON with gitVersion, major, and minor is the signature of a kube-apiserver; note the exact version for CVE matching. -k skips TLS verification because the API server presents its own cluster CA.

Test what anonymous / your token can do

# What can the anonymous identity do?
kubectl --insecure-skip-tls-verify --server https://<target>:6443 auth can-i --list

# Try to read the cluster's crown jewels unauthenticated
kubectl --insecure-skip-tls-verify --server https://<target>:6443 get namespaces
kubectl --insecure-skip-tls-verify --server https://<target>:6443 get pods -A
kubectl --insecure-skip-tls-verify --server https://<target>:6443 get secrets -A

If you hold a leaked token, add --token=<jwt> and re-run auth can-i --list to map its privileges. Any get secrets or create pods result is a critical finding.

Automated Kubernetes attack surface scanning

# kube-hunter (Aqua Security) — remote scan of the API and adjacent services
kube-hunter --remote <target>

# kubeletctl — pivot to the kubelet API on 10250 if reachable
kubeletctl pods --server <target>

Peirates (InGuardians) automates the post-access playbook — enumerating tokens, dumping Secrets, and attempting privileged-Pod escapes — once you have a foothold in a Pod or a token.

Metasploit modules (verified to exist)

msfconsole -q
# Enumerate namespaces, pods, secrets, tokens, and version
use auxiliary/cloud/kubernetes/enum_kubernetes
set RHOSTS <target>
set RPORT 6443
run

# Authenticated code execution: spin up a Meterpreter pod (needs a valid token)
use exploit/multi/kubernetes/exec

Both auxiliary/cloud/kubernetes/enum_kubernetes and exploit/multi/kubernetes/exec are real modules in the rapid7/metasploit-framework tree; the exec module requires a valid service-account JWT and API access. There is no “magic” unauthenticated RCE module for the API server — access hinges on the cluster’s auth config.

Log every open port 6443, the API version, the anonymous/auth can-i results, and any Secret or privileged-Pod path you confirm straight into the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

Be honest about the threat model here: on port 6443 the dominant risk is misconfiguration — anonymous auth plus over-permissive RBAC — not a single CVE. No exploit code is needed when a ClusterRoleBinding already grants system:anonymous the rights to read Secrets or create Pods; a curl or a kubectl command is the whole attack. That said, the API server has had genuine, high-severity CVEs worth checking the version against:

• CVE-2018-1002105 — The infamous Kubernetes API server proxy privilege-escalation flaw (CVSS 9.8). Incorrect handling of error responses to proxied upgrade requests in kube-apiserver let a crafted request establish a connection to a backend (e.g. an aggregated API server or a kubelet) and then send arbitrary requests over it, authenticated with the API server’s own credentials — escalating an ordinary or even unauthenticated user toward cluster-admin. Fixed in v1.10.11, v1.11.5, v1.12.3.
• CVE-2019-11247 — The API server mistakenly allowed access to a cluster-scoped custom resource as if it were namespaced (CVSS 8.1). A user with only namespace-level RBAC on a resource type could create, read, update, or delete the cluster-scoped instance, bypassing the intended cluster-level authorization. Fixed in 1.13.9, 1.14.5, 1.15.2.
• CVE-2020-8558 — A localhost-boundary bypass in the kubelet/kube-proxy components (CVSS 8.8): services bound to 127.0.0.1 on a node became reachable from adjacent hosts on the same LAN or from other Pods on the node. On older clusters this could expose control-plane services that were assumed to be loopback-only. Fixed across the 1.16.11 / 1.17.7 / 1.18.4 line.

Match the gitVersion you fingerprinted against these fix versions before assuming a cluster is vulnerable — a patched control plane closes all three, which is why the RBAC/anonymous-auth review is the higher-yield test on almost every modern cluster.

Mitigation

• Disable anonymous auth. Run the API server with --anonymous-auth=false so an unauthenticated request is rejected outright, and audit every ClusterRoleBinding/RoleBinding for grants to system:anonymous or the system:unauthenticated group — remove them.
• Enforce least-privilege RBAC. Never bind humans or service accounts to cluster-admin for convenience. Scope roles to the namespaces and verbs actually needed, and periodically run kubectl auth can-i --list as low-privilege identities to catch drift.
• Firewall 6443 to the control plane and operators. The API endpoint should not answer from 0.0.0.0 on the public internet; restrict it to the control-plane subnet, a bastion, or an authenticated VPN, and review cloud security groups for an accidental world-open 6443/8443/443. Any exposed control plane you confirm belongs in the pentest report with the exact auth can-i evidence.
• Lock down Pod creation. Enforce Pod Security Admission (restricted) or an admission controller (OPA/Gatekeeper, Kyverno) to block privileged, hostPath, and host-namespace Pods, closing the create-Pod → node-escape path.
• Protect the neighbours. Require kubelet authentication/authorization on 10250 and enforce TLS + client-cert auth on etcd 2379 — an attacker who can’t get through 6443 will try them next.
• Rotate and scope tokens. Treat leaked kubeconfigs and service-account tokens as credentials: keep them out of Git and images, use short-lived/bound tokens, and rotate anything that may have been exposed. Front public access with proper auth and TLS on 443 or 8443 rather than a raw open control plane.

Real-World Example

The canonical port-6443 compromise starts with a single over-broad binding, not an exploit. A team debugging a permissions problem applies a ClusterRoleBinding that grants cluster-admin to the system:unauthenticated group (or to system:anonymous) to “make it work,” and never removes it. Because the API server ships with --anonymous-auth=true, any request that reaches 6443 without credentials is now treated as a full cluster administrator. An attacker who finds the endpoint exposed runs kubectl --insecure-skip-tls-verify --server https://<host>:6443 get secrets -A, dumps every Secret — cloud keys, database passwords, service-account tokens — and then POSTs a privileged, hostPath: /-mounting Pod to read the node’s filesystem and escape to the host. No CVE, no exploit binary — just a misconfiguration and curl.

This mirrors well-documented real incidents. The 2018 Tesla breach disclosed by RedLock began with an internet-exposed Kubernetes administrative console left open with no password; attackers walked in, found AWS credentials inside the cluster, and ran a cryptomining operation on Tesla’s infrastructure. The exposed surface there was a console rather than 6443 specifically, but the lesson is identical to the kubectl-proxy exposure on 8001: an unauthenticated door into the Kubernetes control plane, on whatever port it happens to sit, is a full-environment compromise.

FAQ

What is port 6443 used for?

Port 6443 is the default HTTPS port for the Kubernetes API server (kube-apiserver), the control-plane component that serves the cluster’s REST API. Every kubectl command, controller, kubelet, and automation tool talks to the cluster through this port over TLS. Some distributions use 8443 or 443 instead, but 6443 is the upstream default.

Is an exposed Kubernetes API server on 6443 dangerous?

Very, if authentication or authorization is misconfigured. The API server can read and write all cluster state, so an attacker who reaches 6443 and is granted rights — via anonymous auth plus a permissive RBAC binding, or via a leaked token — can read every Secret, create privileged Pods that escape to the nodes, and take over the whole cluster. A correctly locked-down API server (no anonymous rights, least-privilege RBAC, firewalled) is far safer even when reachable.

How do I tell if the API server allows anonymous access?

Query it without credentials: curl -k https://<host>:6443/version confirms it’s a kube-apiserver, and kubectl --insecure-skip-tls-verify --server https://<host>:6443 auth can-i --list shows what the anonymous identity is permitted to do. If that returns anything beyond trivial self-review permissions — especially get secrets or create pods — anonymous auth is granting real RBAC rights and must be fixed.

Does port 6443 have a single big CVE?

Not really — the dominant risk is a misconfiguration (anonymous auth + over-permissive RBAC), not one exploit. There are genuine high-severity CVEs to check the version against, chiefly CVE-2018-1002105 (the API-proxy privilege-escalation flaw, CVSS 9.8), CVE-2019-11247, and CVE-2020-8558, but a patched, well-configured control plane closes all of them, which is why the RBAC/anonymous-auth review is the higher-yield test.

What are 10250 and 2379 in relation to 6443?

They are the neighbouring control-plane services. Port 10250 is the kubelet API on each node (a shell-into-Pods and node-compromise target if it allows unauthenticated access), and 2379 is etcd, the cluster’s backing key-value store where all state — including Secrets — lives. An attacker probing 6443 will typically scan 10250 and 2379 too, since each is a full-cluster path on its own.

How do I secure or close port 6443?

You don’t close it — the cluster needs it — you lock it down. Set --anonymous-auth=false, remove any RBAC binding to system:anonymous/system:unauthenticated, enforce least-privilege RBAC, and firewall 6443 to the control-plane subnet and authenticated operators only. Block privileged/hostPath Pods with Pod Security Admission, protect kubelet 10250 and etcd 2379, and keep kubeconfigs and tokens out of Git and images.

TL;DR

• Service: Kubernetes API server (kube-apiserver) — the cluster control-plane’s HTTPS REST endpoint (also seen on 8443/443 on some distros)
• Default port: 6443/TCP (HTTPS with the cluster CA)
• Biggest risk: a misconfiguration — anonymous auth plus an over-permissive RBAC binding (or a leaked kubeconfig/token) — that lets an attacker read every Secret, create privileged Pods, exec into workloads, and take over the nodes. It’s usually a config problem, not a single CVE (though CVE-2018-1002105, CVSS 9.8, is a real one to patch)
• Mitigation: --anonymous-auth=false, least-privilege RBAC with no cluster-admin shortcuts, firewall 6443 to the control plane and operators, block privileged/hostPath Pods, protect kubelet 10250 and etcd 2379, and rotate exposed tokens