Kubernetes Hardening: RBAC, Network Policies and Pod Security in Production
Introduction
Running Kubernetes without security hardening is like leaving your server room unlocked. This guide covers Pod Security Standards, RBAC, and Network Policies.
1. Pod Security Standards
In Kubernetes 1.25 and above, apply the Restricted profile to every application namespace. This prevents privilege escalation, forces non-root users, and drops all Linux capabilities by default.
2. Compliant Pod Spec
Set runAsNonRoot to true, runAsUser to 1000, allowPrivilegeEscalation to false, readOnlyRootFilesystem to true, and drop ALL capabilities. Without these your pod is rejected under the Restricted profile.
3. RBAC Least-Privilege
Never bind cluster-admin to application service accounts. Create one Role per service with only the verbs it needs — get, list, watch. Bind it with a RoleBinding scoped to one namespace only.
4. Network Policies
Start with a default-deny NetworkPolicy blocking all ingress and egress. Then whitelist only the specific ports and namespaces each service needs. This gives you zero-trust networking inside your cluster.
Key Takeaways
- Apply Restricted Pod Security Standards from day one
- Drop ALL capabilities and use readOnlyRootFilesystem
- One ServiceAccount per service with minimal verbs
- Default-deny first, then whitelist traffic explicitly
- Audit with kubectl auth can-i after every deployment
Visit My GitHub VARELITE