Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

TCP 6443 is a useful clue when looking for internet-reachable Kubernetes API servers, but a hit does not prove that a service is Kubernetes, unauthenticated, or compromised—and a scan of 6443 alone will miss APIs using other ports. Measure only assets your organization is authorized to assess, verify candidate endpoints against inventory and configuration, and restrict any access that is not needed.

What an open port 6443 does—and does not—tell you

Kubernetes documents that, by default, the API server listens on port 6443 on the first non-localhost network interface and uses TLS. The secure port can be changed with --secure-port, and the listening IP can be changed with --bind-address. In typical production deployments, the API may instead serve on port 443. A 6443 observation is therefore a search clue, not a complete fingerprint or a count of all public Kubernetes APIs. See Kubernetes: Controlling Access to the Kubernetes API.

A reachable TCP listener establishes network reachability from the vantage point and at the time of observation. It does not establish the listener’s identity, whether it demands authentication, what an authenticated identity can do, or whether an attacker can compromise the cluster. HTTPS/TLS, authentication, authorization, endpoint identity and network policy all affect what the observation means. Kubernetes describes HTTPS and client authentication for API traffic and recommends authorization controls; the API server is the main entry point for users and services interacting with a cluster. See Kubernetes access control and Kubernetes security: Controlling access.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

For a separate, specific caveat, Kubernetes documentation notes that in its described default configuration the API server does not verify the kubelet serving certificate. It recommends configuring --kubelet-certificate-authority or using SSH tunneling where needed to avoid an untrusted or public network. That concerns API-server-to-kubelet communication; it is not evidence that a publicly reachable API listener is exploitable.

Is it safe to expose the Kubernetes API server publicly?

NSA and CISA guidance says the API server should not be exposed to the Internet or an untrusted network, and recommends protecting TCP 6443 with a firewall that permits expected traffic. The guidance also identifies complementary control-plane protections, including TLS, strong authentication, RBAC, securing etcd and protecting kubeconfig files. Read the NSA/CISA Kubernetes Hardening Guidance, version 1.2 (August 2022).

Kubernetes’ security checklist likewise advises restricting external Internet access to the API server. It warns that many managed distributions expose API servers publicly by default; that is a caution in the checklist, not a claim that every provider or configuration does so. Where remote administration is necessary, a bastion or other controlled access path can reduce direct exposure. The same checklist says kubelet API access should be restricted and not exposed publicly. See Kubernetes Security Checklist.

Public reachability and weak access control are different findings. Treat internet accessibility as an exposure to justify and constrain, then separately establish endpoint identity and assess its authentication and authorization. Do not label an endpoint “unauthenticated” from a port scan alone.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

How to find exposed Kubernetes API servers in an authorized scope

  1. Define scope and ownership. Record the public IP ranges, domains and managed control-plane endpoints your organization owns or is authorized to assess. Set an observation window, list exclusions and timestamp the scope. CISA recommends first identifying internet-accessible assets and repeating the review routinely; see CISA Internet Exposure Reduction Guidance (June 4, 2025).
  2. Search beyond 6443. Include TCP 6443, common HTTPS port 443 and organization-specific API ports and addresses identified from configuration or inventory. A port match is a candidate, not proof of Kubernetes identity; production services may use 443, and operators can change the secure port and bind address.
  3. Validate candidates with low-impact, authorized checks. Compare findings with the asset inventory and actual cluster configuration. Record whether the listener is reachable, what evidence identifies it as a Kubernetes API endpoint, whether authentication is enforced, and whether its access path is intentional. This is a practical measurement protocol, not a standardized method prescribed by Kubernetes or CISA.
  4. Classify observations separately. Keep public reachability, verified Kubernetes API identity, authentication/access-control observations and policy deviations as distinct fields. Do not turn an open-port result into a claim of unauthenticated access or successful compromise.
  5. Restrict unnecessary exposure and reassess. Remove public access that is not required. For necessary access, limit allowed sources and apply suitable network controls; NSA/CISA specifically recommends firewall restrictions. CISA also gives examples for remaining exposed assets such as patching, a jump host, traffic monitoring and MFA where possible. Repeat the assessment and preserve comparable scope, method and timestamps so changes can be interpreted.

Using internet-wide discovery services responsibly

CISA’s 2025 exposure guidance names Shodan, Censys, Thingful and Shadowserver as possible specialized discovery resources. Its descriptions include device banners and search filters for Shodan; asset identification and data/API ingestion options for Censys; and IPv4 scanning with daily reports to network owners and defenders for Shadowserver. CISA says inclusion does not imply government endorsement. Verify current functionality independently, and use results to investigate assets within your authorized scope rather than treating a platform’s index as your inventory.

These services are leads, not a definitive census. Index coverage, scan timing, selected ports and endpoint identification can all affect findings. The cited guidance does not establish a head-to-head completeness or accuracy benchmark for these services, so compare them against your own inventory and validated configuration rather than presenting their counts as total exposure.

How to reduce and govern API exposure

  • Decide whether public access is necessary. CISA recommends identifying internet-accessible assets, evaluating operational need, and removing or restricting unnecessary exposure.
  • Constrain access that must remain. Apply network restrictions to expected sources and use a controlled administration path, such as a jump host, where appropriate. Protect identities with strong authentication and authorization, including RBAC, and monitor relevant traffic.
  • Protect the surrounding control plane. Follow the NSA/CISA guidance for TLS, etcd, kubeconfig files and other control-plane safeguards; network restriction is not a substitute for these controls.
  • Make assessment recurring. Revisit public assets as infrastructure changes, recording scope and timestamps to distinguish a real change from a change in scan coverage.

CISA’s Binding Operational Directive 23-02, announced June 13, 2023, requires Federal Civilian Executive Branch agencies to remove covered internet-exposed networked management interfaces or protect them using Zero Trust capabilities with a policy enforcement point separate from the interface. CISA recommends that other stakeholders review and adopt the guidance, but the directive itself is not binding on every organization. See CISA’s BOD 23-02 announcement.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Can a scan tell how many Kubernetes APIs are exposed worldwide?

No reliable global prevalence figure is established by the cited sources. A defensible count would need a reproducible population, observation date, scan method, port coverage and validation of endpoint identity. Since 6443 is not the only port used, a 6443-only tally would also undercount APIs on alternate ports; broad port hits, in turn, can include services that are not Kubernetes APIs. Report the scope, vantage point, time and validation criteria for organizational measurements rather than presenting a scan result as a global total.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.