Secure the Kubernetes API server

The fix/etc/kubernetes/manifests/kube-apiserver.yaml

spec:
  containers:
    - command:
        - kube-apiserver
        - --anonymous-auth=false
        - --authorization-mode=Node,RBAC
        - --profiling=false
        - --audit-log-path=/var/log/kubernetes/audit.log

On a managed cluster (EKS/GKE/AKS) this is the provider’s job — you can’t set these flags, and shouldn’t need to. This page is for self-managed control planes.

Why it matters

The API server is the single front door to everything: workloads, secrets, RBAC, nodes. Every kubectl command, every controller, every pod’s service account talks to it. Compromise it and you have the cluster; expose it carelessly and you invite the attempt.

Three flags carry most of the risk.

anonymous-auth

--anonymous-auth=true lets requests that present no credentials through to the authorization stage as the user system:anonymous. On its own that’s not fatal — RBAC still has to grant anonymous something — but it’s a foot-gun: a single over-broad ClusterRoleBinding to system:unauthenticated (which people create by accident, or copy from a bad tutorial) turns anonymous into real access.

--anonymous-auth=false removes the category. There’s rarely a reason for anonymous API access; the health endpoints that legitimately need it (/livez, /readyz) can be allowed explicitly.

authorization-mode

--authorization-mode=Node,RBAC is what you want. The danger values:

• AlwaysAllow — every authenticated request is permitted. RBAC is not consulted. This is catastrophic and occasionally appears in dev clusters that escaped to production.
• Missing RBAC — if RBAC isn’t in the authorizer chain, none of your carefully scoped roles are enforced.

Node restricts what kubelets can read to what their own pods need; RBAC enforces everything else. Both, in that order.

Don’t expose it, and mind the unauthenticated endpoints

The API server should be reachable by your operators and nodes, not the internet. On a self-managed cluster that means binding it appropriately and firewalling 6443. Even authenticated, an internet-facing API server is a continuous brute-force and CVE target.

And a few endpoints answer before authentication:

• /healthz, /livez, /readyz — fine, but they confirm a cluster is there.
• /metrics — should require auth; unauthenticated metrics leak cluster internals.
• --profiling=true exposes /debug/pprof, which can leak memory contents. Turn it off in production.

Verify it worked

Check the flags on the running API server:

sudo grep -E 'anonymous-auth|authorization-mode|profiling' /etc/kubernetes/manifests/kube-apiserver.yaml

Or, on any cluster, from the process:

kubectl -n kube-system get pod -l component=kube-apiserver \
  -o jsonpath='{.items[0].spec.containers[0].command}' | tr ',' '\n' | grep -E 'anonymous|authorization|profiling'

--anonymous-auth=true or --authorization-mode=AlwaysAllow is the finding.

Prove anonymous access is refused — a request with no credentials:

kubectl get --raw / --as=system:anonymous 2>&1 | head -1
curl -sk https://your.api:6443/api/v1/namespaces/kube-system/secrets -o /dev/null -w '%{http_code}\n'

Expect 401/403. A 200 returning secrets with no credential is a total compromise.

Check nothing granted anonymous real access:

kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.subjects[]?.name=="system:unauthenticated" or .subjects[]?.name=="system:anonymous") | .metadata.name'

Any output there is anonymous access to whatever that role grants.

Confirm the API server isn’t internet-reachable — from outside:

curl -sk --connect-timeout 5 https://your.api:6443/version -o /dev/null -w '%{http_code}\n'

A timeout is best; a response means it’s reachable and relying entirely on auth.

Before you apply this

Editing the static manifest restarts the API server. On a single-control-plane cluster that’s a brief control-plane outage — running workloads keep serving traffic, but no new deployments, scaling, or kubectl until it’s back. The kubelet restarts the pod automatically when you save the file; a syntax error leaves the API server down, so keep a backup and know how to read the kubelet logs:

sudo cp /etc/kubernetes/manifests/kube-apiserver.yaml /root/apiserver.bak
sudo journalctl -u kubelet -f    # watch it come back after editing

--anonymous-auth=false breaks anything relying on anonymous access — most often a monitoring probe or load-balancer health check hitting an endpoint that now requires auth. Check what’s calling the unauthenticated paths first, and if a health check needs one, allow that specific path rather than re-enabling anonymous globally.

Multi-control-plane clusters need a rolling change. Edit one API server at a time and confirm it rejoins healthy before the next, or you can lose quorum on the control plane.

Do not experiment with --authorization-mode on the only control plane. Get it wrong (drop RBAC, or fat-finger to AlwaysAllow) and you’ve either locked everyone out or opened everything. Test authorization changes on a throwaway cluster.

Related

• RBAC least privilege — only enforced if RBAC is the authorizer.
• Secure etcd — the API server’s data store, equally sensitive.
• Kubernetes cluster exposed — what a reachable API server invites.