Kubernetes Security & Hardening Workflow | CIS Benchmark

📚 Part of the MTA-STS and TLS-RPT Guide: Enforcing Email Encryption in Transit series.

Kubernetes ships insecure by default — permissive RBAC, no network policies, containers running as root, and secrets in plain environment variables. Hardening a cluster means closing those gaps systematically across the control plane, workloads, network, and supply chain. This guide is the hub for our Kubernetes security coverage; start with the area you're securing.

What to harden, and where to go deep

• Workload & container baseline — non-root users, read-only filesystems, dropped capabilities, resource limits. See Container Security Best Practices and the Kubernetes & Container Security Complete Guide.
• Pipeline & supply chain — image scanning, signed images, admission control in CI/CD. See DevOps CI/CD Security Complete Guide.
• Transport security — TLS for ingress, API server, and etcd. See the TLS Configuration Hardening Guide.

The hardening checklist (high level)

1. RBAC — least privilege; no wildcard roles; audit service-account tokens.
2. Network policies — default-deny, then allow-list pod-to-pod traffic.
3. Pod security — enforce the restricted Pod Security Standard via admission.
4. Secrets — external secret stores or encryption-at-rest, never plain env vars.
5. Supply chain — scan and sign images; block unsigned/critical-CVE images at admission.
6. Runtime — audit logging, drift detection, and a tested incident-response path.

Validate your manifests against these controls with the tool above before you apply them.