Kubernetes defaults are permissive by design. Production clusters require layered security: RBAC for access control, network policies for traffic segmentation, admission controllers for runtime enforcement, and supply-chain verification for images.
RBAC and least-privilege access
Start with namespace-scoped roles that grant minimum permissions. Avoid cluster-admin for service accounts and audit who has access to secrets, configmaps, and node resources. Use tools like kube-bench to validate CIS Kubernetes Benchmark compliance.
Integrate with identity providers (OIDC, LDAP) so users authenticate with corporate credentials, not shared kubeconfig files. Rotate service account tokens regularly and bind them to specific pods.
Network policies and micro-segmentation
Default-deny network policies ensure pods communicate only with explicitly allowed services. Define ingress and egress rules per namespace, blocking lateral movement if a pod is compromised.
Service meshes like Istio or Linkerd add mTLS between workloads, enforcing identity-based policies and encrypting pod-to-pod traffic. This aligns with zero-trust principles where every connection is authenticated and authorized.
Admission control and image scanning
OPA Gatekeeper or Kyverno enforce policies at admission time: require signed images, block privileged containers, mandate resource limits, and validate labels. These guardrails prevent misconfigurations from reaching the cluster.
Scan container images in CI and at runtime. Tools like Trivy, Grype, or cloud-native registries flag CVEs before deployment. Use image provenance and SBOM (Software Bill of Materials) to track dependencies and respond quickly to supply-chain vulnerabilities.
Key takeaways
- RBAC + OIDC for identity-based access control
- Network policies + service mesh for zero-trust networking
- Admission controllers + image scanning to prevent misconfigurations