Skip to main content
In this guide, we explore how the kubectl CLI communicates with the Kubernetes API server and demonstrate two secure methods—kubectl proxy and kubectl port-forward—for accessing cluster APIs and Services locally. You’ll see how kubeconfig provides authentication, how to launch a local HTTP proxy, and how to forward ports from your machine to in-cluster endpoints.

​
1. Interacting with the Kubernetes API

By default, kubectl uses credentials in your ~/.kube/config (kubeconfig) to authenticate against the API server:
Example output:
If you call the API directly over HTTPS without credentials, you’ll get a 403 error:
Supplying client certificates lets you authenticate:
This returns a list of available API paths:

​
Comparison of Access Methods

​
2. Using kubectl proxy

The kubectl proxy command starts a local HTTP server (default port 8001) that forwards requests to the API server using your kubeconfig credentials:
Now you can access the API via http://localhost:8001:
By default, kubectl proxy listens only on the loopback interface (127.0.0.1) for security.
Avoid exposing the proxy on public IPs without proper authentication controls.

​
3. Accessing In-Cluster Services via Proxy

You can also reach Services of type ClusterIP inside the cluster through the proxy. For example, to access an NGINX Service in the default namespace:
The image illustrates the architecture of a Kubectl Proxy setup, showing the connection between a laptop running Kubectl and a Kubernetes cluster's API server through specific ports.
You’ll receive the standard NGINX welcome page:
With kubectl proxy, the in-cluster Service appears as if it’s running locally.

​
4. Port Forwarding with kubectl port-forward

An alternative to proxying is port forwarding, which maps a local port directly to a Pod or Service port:
  • Local endpoint: http://localhost:8080
  • Cluster endpoint: Service nginx port 80
Now, visiting http://localhost:8080 sends traffic through the API server to the nginx Service.

Watch Video