defending-kubernetes

Defending Kubernetes

Kubernetes is insecure in useful defaults, not in exotic bugs. The attacks that land are RBAC that grants more than intended, pods that run privileged because nothing stops them, a flat pod network, and mounted service-account tokens with cluster-wide reach. Defense is mostly closing those, in priority order, and being able to see when someone tries.

This is the counterpart to attacking-eks-gke-aks and exploiting-containers: read those to know what the attacker does; use this to know what to enforce and what to watch.

When to Use

• Reviewing a cluster's security posture or an admission/RBAC configuration
• Responding to a suspected cluster compromise (post-triage)
• Deciding what to enforce (Pod Security, network policy) and what to detect
• Translating an offensive cluster finding into a concrete control
• Hardening the control plane, kubelet, or etcd exposure

When NOT to Use

• Attacking the cluster — use attacking-eks-gke-aks
• Container escape and runtime internals specifically — use exploiting-containers / escaping-hardened-containers for the technique; return here for the control
• The cloud IAM plane around the cluster (IRSA, workload identity, node role) — that is investigating-*-incidents / hardening-cloud-posture; a GKE/EKS/AKS incident usually needs both planes
• Whether an alert is an incident — use triaging-security-alerts

Enforce in Priority Order

Order matters — these are ranked by how often the gap is the actual entry path.

1. RBAC least privilege

The most common real weakness. Look for the bindings that are escalation primitives regardless of how innocent they look:

# Who can create pods anywhere? (→ mount any secret, run as any SA)
kubectl auth can-i create pods --all-namespaces --as=system:serviceaccount:ns:sa

# Subjects bound to cluster-admin
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'