Kubernetes Security in Production: From Pod Security Standards to Network Policies

Pod Security Policies were removed in Kubernetes 1.25. The replacement, Pod Security Standards, defines three levels — privileged, baseline, restricted — and is enforced via labels on namespaces:

apiVersion: v1
kind: Namespace
metadata:
  name: prod
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest

Default every workload namespace to restricted. Make exceptions explicit, time-bound, and tracked.

The most common K8s RBAC mistake is granting cluster-admin to a service account because "the deployment kept failing." The fix path:

• Start at view at namespace scope. Add specific verbs as the workload needs them.
• Avoid * in resources, verbs, and apiGroups.
• Audit roles regularly — RBAC creep is real. Tools like krane and rbac-lookup help.
• Never grant the ability to create or modify RoleBindings / ClusterRoleBindings outside admin contexts — that's a privilege-escalation pivot.

By default, every pod can reach every other pod. That's a flat L7 network — fine in dev, terrible in prod. The pattern that holds up:

• Default deny at the namespace level — both ingress and egress.
• Allowlist the specific traffic your workload needs.
• CNI choice matters — Calico, Cilium, and (recently) the default kubeadm setups support NetworkPolicies. AWS VPC CNI requires explicit enablement.
• Cilium adds L7 policy (HTTP method, path, gRPC service) — useful for east-west microservice traffic.