Hardening a Cluster

Every attack path in this module closes if you take away the defaults nobody changed.

20 minkubernetesk8shardeningdefense

What you will learn

-Lock down pod-to-pod traffic with network policies
-Strip pod privileges with Pod Security Standards
-Cut RBAC and service-account permissions to what a workload actually needs

Almost every compromise you just learned about traces back to a default that shipped open and stayed open. Flat networking. A mounted into every pod. roles copied from a tutorial. Harden those and the attacker who lands in one pod stays stuck in that pod.

Default-deny the network

Out of the box, any pod can talk to any other pod. That is how a single web pod turns into cluster-wide reconnaissance. A NetworkPolicy changes that, but only if your CNI plugin enforces it (Calico and Cilium do, plain flannel does not).

Start by denying everything in a , then add back only what a workload needs.

operator@workstation

# know your labels before you write policy

$kubectl get pods -n prod --show-labels

# deny all ingress, then allow-list

$kubectl apply -f default-deny.yaml -n prod

# confirm blocked traffic actually fails

$kubectl exec -n prod web-0 -- curl -m 3 http://db.prod:5432

The last command matters. Write the , then prove from inside a pod that the path you meant to close is closed. Policies that were never tested are policies that quietly do nothing.

Take away pod privileges

A pod does not need to run as , mount the filesystem, or the host's process namespace. Almost none do, yet the defaults allow all of it. Pod Security give you three levels, and restricted is the one you want for anything untrusted.

Enforce, do not just warn

The built-in Pod Security Admission runs in three modes: warn, , and enforce. Label a namespace with enforce and the rejects a pod that tries to run privileged or as root. Warn-only mode looks like security and stops nothing.

kubectl label namespace prod \
  pod-security.kubernetes.io/enforce=restricted

That one label blocks privileged pods, host mounts, and host namespaces across the whole namespace. It is the single highest-value setting in this lesson.

Cut RBAC and the service-account token

The token mounted into a pod is only dangerous because of what its service account can do. Give each workload its own service account, bind it to the narrowest Role you can, and turn off the automatic token mount when a pod does not call the API at all.

attacker@kali

$kubectl auth can-i --list --as=system:serviceaccount:prod:web

Ask the API exactly what a service account can do. If it can read secrets or create pods and it is a web frontend, that is your finding.

Set automountServiceAccountToken: false on pods that never touch the API. No token in the pod means nothing for an attacker to steal from it.

Watch the audit log

Hardening is not one-and-done. Turn on the API server audit and on the calls that matter: exec into a pod, reading , creating a ClusterRoleBinding, or anything hitting the kube-system namespace from an unexpected . Those are the exact moves the attacking-a-cluster lesson made, and they are loud if you are .

Which Pod Security Admission mode actually prevents a privileged pod from being created?

Exercise

What is the kubectl subcommand that lists every action a given identity is allowed to take?

Attacking a Cluster