Hardening Kubernetes

Kubernetes is not one service to harden — it’s a control plane, a data store, a network fabric, and a runtime, each with its own security model, wired together. That’s why it gets a longer checklist than anything else on this site, and why the failure modes are less “one bad setting” and more “a default that’s convenient at small scale and dangerous at real scale.”

Two facts sit underneath most of it:

• Secrets are not encrypted by default. They’re base64-encoded, which is not encryption, and stored in etcd in the clear unless you turn on encryption at rest.
• The default posture is permissive. Pods talk to any other pod (no network policy), mount a service account token that can reach the API, and — without Pod Security Admission — can request privilege the node will grant.

9 controls

• Grant least privilege with Kubernetes RBACAn over-bound credential is control of the entire clusterSeverity: critical
• Secure the Kubernetes API serverThe API server is total cluster control on one endpointSeverity: critical
• Encrypt Kubernetes secrets at restSecrets sit in etcd in plaintext, readable by anyone with etcd accessSeverity: critical
• Enforce Pod Security AdmissionWithout it, a pod can request the privilege that owns the nodeSeverity: high
• Disable Kubernetes service account token automountA compromised pod uses its mounted token to query the clusterSeverity: high
• Apply Kubernetes network policiesFlat pod networking lets a compromised pod reach everythingSeverity: high
• Restrict privileged Kubernetes containersA privileged pod is a route to the node it runs onSeverity: high
• Secure etcdetcd is the whole cluster, secrets included, in one data storeSeverity: high
• Enable Kubernetes audit loggingNo record of who accessed or changed anything in the clusterSeverity: medium

Version, and the advice that expired

kubectl version

1.34 is the current line (mid-2026). Kubernetes moves fast and removes things, which is why old hardening guides are actively misleading:

• PodSecurityPolicy was removed in 1.25. Any guide telling you to write a PSP is describing an API that no longer exists. Its replacement is Pod Security Admission, and they work completely differently.
• The insecure API port (8080) is gone. Guides warning you to disable it are describing a risk that was removed years ago.

Kubernetes’ own support window is roughly the three most recent minor versions — about a year. A cluster more than a few minors behind is unsupported and accumulating unpatched CVEs regardless of anything on this list. Patching the control plane and nodes is the control that outranks all of them.

Managed clusters do some of this for you

If you’re on EKS, GKE or AKS, the provider manages the control plane — the API server, etcd, and their TLS — and several items here are partly or fully handled: etcd encryption is often on by default, the control plane isn’t yours to expose, and audit logging may be a checkbox. What’s still yours: RBAC, workload security context, network policies, service account tokens, Pod Security Admission, and image provenance. This checklist covers self-managed clusters; on managed ones, the control-plane pages (etcd, API server) become “verify the provider did it” rather than “do it yourself.”

Where the config lives

There’s no single config file — Kubernetes is configured through API objects (kubectl apply) and, for the control plane, static manifests and flags:

kubectl config current-context            # which cluster you're pointed at
kubectl cluster-info
kubectl get --raw /livez?verbose          # control-plane health

# self-managed control plane (kubeadm):
sudo ls /etc/kubernetes/manifests/        # kube-apiserver.yaml, etcd.yaml, ...

The API is the source of truth for workload settings; the static manifests are the source of truth for the control plane’s own flags.

A note on the tooling

The verification on these pages uses kubectl, and much of it needs cluster-admin to run in full — which is itself worth noting: kubeconfig with cluster-admin is root for the whole cluster. Treat the admin kubeconfig like a root SSH key, and see RBAC for why almost nobody should be using it day to day.