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'

The dangerous verbs are not just *. create pods lets a subject run a pod as any service account in the namespace and mount any secret — effectively namespace-admin. escalate and bind on roles let a subject grant themselves more than they hold. create on pods/exec, and access to secrets, serviceaccounts/token, and nodes/proxy are each escalation paths. Enumerate what subjects can do, not what their role is named.

2. Pod Security Admission

PodSecurityPolicy was removed in Kubernetes 1.25; the built-in replacement is Pod Security Admission, which enforces the three Pod Security Standards levels — privileged, baseline, restricted — per namespace via labels:

# Namespace label: enforce the restricted profile, and warn/audit on violations
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/audit: restricted

restricted blocks the pod configurations that make escape and privilege escalation easy: privileged containers, host namespaces (hostPID, hostNetwork, hostIPC), host-path mounts, running as root, added capabilities. A cluster with no enforced profile is one securityContext.privileged: true away from a node takeover. If you need policy beyond the three levels (image provenance, registry allow-lists), that is an external admission controller (Kyverno, OPA Gatekeeper) — note it, do not pretend PSA covers it.

3. Network policy default-deny

By default every pod can reach every other pod. A default-deny ingress policy per namespace, with explicit allows, is what stops a single compromised pod from becoming lateral movement. Confirm the CNI actually enforces NetworkPolicy — some configurations accept the objects and enforce nothing, which is worse than none because it looks covered.

4. Service-account tokens and secrets

• automountServiceAccountToken: false on pods that do not call the API. A mounted token plus a permissive RBAC binding is the standard in-cluster pivot.
• Kubernetes Secrets are base64, not encrypted, in etcd unless encryption-at-rest is configured. Confirm it is.
• Look for tokens and cloud credentials passed as env vars — they leak into logs and crash dumps.

5. Control-plane and kubelet exposure

• The API server should not be internet-facing without authn/authz and, ideally, network restriction. Anonymous auth must be off.
• The kubelet read-only port (10255) and the authenticated port (10250) must not be reachable from workloads; nodes/proxy RBAC and an exposed 10250 are a direct route to command execution on nodes.
• etcd must require mutual TLS — etcd access is game-over, it holds every secret.