Securing Kubernetes clusters: A practical checklist

Kubernetes is not secure by default

Kubernetes gives you incredible flexibility in running containerised workloads. It also gives you incredible flexibility in making dangerous mistakes. The default configuration prioritises functionality over security.

This checklist covers the most impactful hardening steps we implement for every production cluster.

1. Role-Based Access Control (RBAC)

Disable anonymous authentication and enforce RBAC. Every service account should have the minimum permissions required. Never use the cluster-admin role for application workloads.

# Check for cluster-admin bindings
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | \
  {subjects: .subjects, name: .metadata.name}'

2. Network Policies

By default, all pods in a Kubernetes cluster can communicate with each other. Network policies restrict this to explicitly allowed flows. Start with a default-deny policy and add exceptions as needed.

3. Pod Security Standards

Prevent pods from running as root, mounting host paths, or using privileged mode. Kubernetes Pod Security Standards (replacing the deprecated PodSecurityPolicy) provide three levels: Privileged, Baseline, and Restricted. Aim for Restricted where possible.

4. Image Security

Use minimal base images (distroless, Alpine). Scan images for vulnerabilities in your CI pipeline. Enforce image signatures using tools like Cosign. Never pull images from untrusted registries.

5. Secrets Management

Kubernetes Secrets are base64-encoded, not encrypted. Use an external secrets manager (AWS Secrets Manager, HashiCorp Vault) with a secrets operator to inject credentials at runtime.

6. Audit Logging

Enable Kubernetes audit logging and ship logs to a centralised system. You need visibility into who did what, when, and where — especially for security-relevant events.