How do you control who can reach and use the Kubernetes API?
You control access to the Kubernetes API in four layers: limit which networks can reach the API server endpoint, authenticate every caller with short-lived credentials from your identity provider, authorize each request with least-privilege RBAC, and record what happened in audit logs stored outside the cluster. The API server is the single entry point to a cluster, so anyone who can reach it with a valid credential and enough permissions controls every workload. Each layer covers a failure in the one before it.
Every request passes the same stages
The controlling access guide describes the path of a request: it reaches the API server over TLS, an authenticator establishes who the caller is, an authorizer (usually RBAC) decides whether that caller may perform the action, admission controllers can modify or reject it, and the audit subsystem records it. Network controls sit in front of all of this. Authorization has its own article, Kubernetes RBAC. This one covers the other layers.
Network exposure of the API endpoint
| Option | How it works | Trade-off |
|---|---|---|
| Public endpoint, open | Reachable from the internet; protection relies on authentication | Exposed to scanning and to any future authentication bug |
| Public endpoint with an IP allow list | Only listed source ranges can connect | Breaks for remote staff and CI runners with changing addresses |
| Private endpoint | Reachable only from a VPC, VPN or peered network | Every client, including CI, needs a network path into it |
| Identity-aware access proxy | Clients connect through a proxy that checks the user’s identity and device before forwarding | One more component to run, but works from anywhere without a VPN |
Managed services offer the first three under their own names, such as authorized networks or authorized IP ranges and private clusters. A private endpoint shrinks the attack surface but does not replace authentication: anything inside the network, including a compromised Pod, can still reach it.
Authentication of callers
Kubernetes has no user objects. A user is whatever name and groups an authenticator reports. The methods differ in how long a credential lives and whether you can revoke it.
| Method | Credential lifetime | Revocation | Use for |
|---|---|---|---|
| Client certificates | Until expiry, often a year or more | No revocation check, so a leaked certificate works until it expires | Bootstrap and break-glass only |
| Static token file | Indefinite; changes need an API server restart | Restart only | Nothing in production |
| Bound service account tokens | Tied to an expiry time and to the Pod that requested them | Deleting the Pod or service account invalidates them | Workloads inside the cluster |
| OIDC tokens from your identity provider | Set by the identity provider, usually an hour or less | Disable the user in the identity provider | All human users, and CI through OIDC federation |
The CIS Kubernetes Benchmark recommends against client certificates for users because of the missing revocation. For people, use single sign-on: kubectl gets an OIDC token through a credential plugin, and the API server validates it against your identity provider. Your identity provider then enforces multi-factor authentication and offboarding, and the groups claim feeds RBAC.
Kubernetes configures OIDC through structured authentication configuration, a file passed with --authentication-config. It has been stable since Kubernetes 1.34. It accepts up to 64 JWT authenticators with different issuers, validates and maps claims with CEL expressions, and reloads when the file changes, with no API server restart. That makes it possible to trust your corporate identity provider for people and your CI provider for pipelines at the same time. The article on workload identity explains the same token exchange for CI jobs and cloud APIs.
Hardening defaults
- Anonymous requests. The API server accepts anonymous requests by default when an authorization mode other than
AlwaysAllowis set. Since Kubernetes 1.34 you can limit anonymous access to/healthz,/livezand/readyzin the authentication configuration, or turn it off with--anonymous-auth=false. Never bind roles tosystem:anonymousorsystem:unauthenticated. - Long-lived tokens. Request bound tokens through the TokenRequest API, for example with
kubectl create token, instead of creating Secrets of typekubernetes.io/service-account-token, which never expire. - Superuser credentials. Members of the
system:mastersgroup bypass RBAC entirely. Keep that group out of everyday kubeconfigs. - Break-glass access. Keep one or two emergency credentials that do not depend on the identity provider, store them in separate vaults, and alert on every use through the audit log.
The kubelet API is a second front door
Every node runs the kubelet, which serves its own HTTPS API, by default on port 10250. It can list Pods, read logs and run commands in containers. The kubelet’s own defaults are permissive: unauthenticated requests are treated as anonymous, and the default authorization mode is AlwaysAllow, according to the kubelet authentication guide. Run kubelets with --anonymous-auth=false and --authorization-mode=Webhook, so the kubelet asks the API server to authorize each request. Block port 10250 from anything except the control plane and monitoring, and treat RBAC access to nodes/proxy as equivalent to running commands on the node.
Audit logs
The API server writes audit events only when you pass a policy with --audit-policy-file. Each rule sets a level:
None: do not log.Metadata: who, when, which verb and which resource, without bodies.Request: metadata plus the request body.RequestResponse: metadata plus request and response bodies.
Log Secrets, ConfigMaps and token requests at Metadata only, so values never end up in the log. Log writes to RBAC objects, Pods with exec or attach, and authentication failures at a level detailed enough to investigate. Send events through the log or webhook backend to storage that cluster administrators cannot modify, because an attacker with cluster-admin will try to erase their tracks. Then alert on the events that matter: new ClusterRoleBindings, pods/exec in production namespaces, reads of many Secrets and any use of break-glass credentials.
A short checklist
- Make the API endpoint private or allow-listed, or put an identity-aware proxy in front of it.
- Authenticate people through OIDC single sign-on with MFA. Keep client certificates for break-glass only.
- Authenticate CI through OIDC federation, not stored kubeconfigs.
- Restrict anonymous access to health endpoints.
- Lock down the kubelet API.
- Apply least-privilege RBAC bound to identity provider groups.
- Ship audit logs to storage outside the cluster and alert on high-risk events.
The same controls are the base layer for sharing a cluster between teams, covered in Kubernetes multi-tenancy.
API access on Cloudfleet
On Cloudfleet Kubernetes Engine (CFKE), people reach clusters through their Cloudfleet account with single sign-on from your identity provider, and GitHub Actions and GitLab CI authenticate with short-lived OIDC tokens instead of stored kubeconfigs. On Enterprise clusters, control plane endpoints can be restricted to private networks and the Kubernetes audit logs are delivered to your own infrastructure, as described on the security page.