6443 Kubernetes API TCP Flagship

What it's for

Port 6443 is the default port for the Kubernetes API server — the central control point of a Kubernetes cluster. Every interaction with a cluster, whether it's kubectl deploying a new pod, a CI/CD pipeline rolling out an update, or an internal controller reconciling desired state, ultimately goes through the API server on this port. It's genuinely the front door to the entire cluster's control plane.

Because the API server has this central role, port 6443 is both the single most important and single most sensitive port in a Kubernetes deployment — full API access is effectively equivalent to full control over everything running in the cluster.

Protocol basics

• Protocol: TCP, carrying HTTPS/REST-style API requests underneath.
• HTTPS by default. The Kubernetes API server serves its API over TLS on port 6443, not plaintext — this isn't optional the way it is for some other services, since API access implies cluster-wide control.
• RESTful, resource-oriented API. Kubernetes models everything (pods, services, deployments, secrets) as API resources accessible via standard REST verbs, which is why tools like kubectl and curl against the API server behave similarly to interacting with any HTTPS REST API.
• Authentication and authorization are layered. A request must first authenticate (client certificates, tokens, OIDC, etc.) and then pass authorization checks (commonly RBAC — Role-Based Access Control) before the API server acts on it.

Security considerations

• Port 6443 should never be open to the unrestricted public internet. Cloud-managed Kubernetes offerings typically let you restrict API server access to specific IP ranges (your office, VPN, or CI system) — use this rather than leaving the endpoint globally reachable.
• RBAC should follow least privilege. Overly broad cluster-admin bindings handed out casually are one of the most common Kubernetes security misconfigurations, since a compromised credential with cluster-admin effectively means full cluster compromise.
• Rotate and protect service account tokens carefully — tokens with API access, if leaked (e.g., accidentally committed to a repo or exposed in a misconfigured pod), grant an attacker direct programmatic access to the cluster.
• Enable audit logging on the API server so administrative actions (especially anything touching secrets or RBAC itself) are traceable after the fact.

Troubleshooting

"Unable to connect to the server: dial tcp ... connect: connection refused":

• Check that the API server is actually running and reachable, and that your network path (VPN, IP allowlist) permits access to port 6443 from where you're connecting

"error: You must be logged in to the server (Unauthorized)":

• Your kubeconfig's credentials (client certificate, token) have expired or are invalid — regenerate credentials or re-authenticate via your cluster's configured auth provider

"error: Forbidden" on specific operations:

• Authentication succeeded, but RBAC is denying the specific action — check the relevant Role/ClusterRole and RoleBinding/ClusterRoleBinding for the user or service account in question

Works with one kubeconfig context but not another:

• Almost always a context/cluster mismatch in your local kubeconfig — verify kubectl config current-context points to the intended cluster and that its API server endpoint and credentials are correct

Comparison / FAQ

Why is exposing port 6443 to the public internet considered risky?

Because the API server is the control point for the entire cluster — unrestricted access, combined with any authentication weakness, could grant an attacker the ability to deploy workloads, read secrets, or otherwise take control of everything running in the cluster.

What's the difference between authentication and authorization on the Kubernetes API?

Authentication verifies who you are (via certificates, tokens, or an external identity provider); authorization (typically RBAC) then determines what that authenticated identity is allowed to do. Both checks happen on every request to port 6443.

Why did my kubectl command suddenly start failing with "Unauthorized"?

Client certificates and tokens used for Kubernetes authentication commonly have expiration windows — this is one of the most frequent causes of a previously working kubeconfig suddenly failing, and usually requires re-authenticating or regenerating credentials.

Can I run kubectl commands without direct network access to port 6443?

Some managed Kubernetes offerings and bastion setups proxy API access through an intermediary (a jump host or cloud provider's web console) rather than requiring a direct network path to 6443, which is a common pattern for keeping the API server itself unreachable from the open internet.