Hardening a Kubernetes cluster: API access, upgrades, auditing and CIS ideas

A layered plan

No single setting makes a cluster secure. Hardening combines controls across the API server, nodes, workloads, network, supply chain and monitoring. If you use a managed service (EKS, AKS, GKE), the provider secures the control plane components, but you still own access, node configuration (unless nodes are also managed), workloads and logging.

Lock down the API server

• Restrict network access. Use a private endpoint, or limit the public endpoint to known admin and CI address ranges. A cluster API open to the internet invites password spraying and exploit attempts.
• Use single sign-on. Authenticate people through OIDC or the cloud IAM integration so MFA and leaver processes apply. Avoid sharing static admin kubeconfig files.
• Disable anonymous access where your platform allows, and never bind anything meaningful to system:anonymous or system:unauthenticated.
• Least-privilege RBAC, with cluster-admin limited to break-glass use. See Kubernetes RBAC.

Nodes and the kubelet

• Use a minimal, container-optimised OS image and replace nodes regularly rather than patching by hand.
• Do not allow SSH to nodes from the internet; use the cloud's session manager or a bastion if access is needed.
• Kubelet: disable anonymous authentication, use webhook authorisation and keep its port off public networks.
• Block pod access to the cloud instance metadata service, or require IMDSv2 with a hop limit of 1 on AWS, so pods cannot borrow the node's cloud role.
• Use separate node pools for sensitive or untrusted workloads with taints and tolerations.

Upgrades, auditing and benchmarks

The Kubernetes project supports roughly the three most recent minor releases, each for about a year, so clusters that are not upgraded regularly fall out of support and stop receiving security fixes. Plan upgrades several times a year, test in a staging cluster and check for removed APIs before each one.

Audit logging records who did what through the API server. Enable it (on managed services it is usually an option to switch on and send to the cloud's log service), keep metadata for most requests, record request bodies for sensitive resources where useful, and never log Secret contents. Alert on events such as new ClusterRoleBindings, pods/exec into production, and changes to admission webhooks.

The CIS Kubernetes Benchmark lists recommended settings for control plane, etcd, kubelet and policies, and the CIS also publishes benchmarks for EKS, AKS and GKE. The open-source kube-bench tool checks a cluster against them:

kubectl apply -f job.yaml        # kube-bench job manifest from the project repository
kubectl logs job/kube-bench

Hardening checklist

Tip: manage cluster configuration as code (Terraform, Helm, GitOps) so hardening settings are reviewed, repeatable and cannot drift quietly.