Kubernetes 1.33 Security Hardening: A Practical Guide for Production Clusters

Kubernetes clusters remain one of the most commonly misconfigured infrastructure components in enterprise environments. Despite years of security tooling maturation and increasing awareness of container security, audit findings consistently show the same categories of misconfigurations appearing repeatedly: excessive RBAC permissions, missing network policies, unscanned images running in production, and secrets stored as plaintext in environment variables. Kubernetes 1.33 introduces improvements to default security posture, but configuration choices made by operators continue to determine actual security outcomes.

RBAC: The Persistent Misconfiguration Problem

Role-Based Access Control is Kubernetes’ primary authorization mechanism, and it is consistently implemented too permissively. The most dangerous pattern is the use of ClusterAdmin or cluster-wide wildcard permissions for service accounts that should have narrow, namespace-scoped access. A compromised pod running with ClusterAdmin permissions can enumerate the entire cluster, read all secrets, and create privileged pods with host network access.

Effective RBAC hardening starts with an audit of existing permissions using tools like kubectl-who-can or Fairwinds Insights to identify over-privileged principals. For each service account, enumerate the actual API calls your application makes and create a Role or ClusterRole that grants exactly those permissions — nothing more. Enforce this discipline for new deployments through admission webhooks that reject service accounts with wildcard permissions.

Pod Security: Beyond Pod Security Policies

Pod Security Admission (PSA), which replaced the deprecated Pod Security Policies in Kubernetes 1.25, enforces three security profiles: privileged (no restrictions), baseline (preventing known privilege escalations), and restricted (following current hardening best practices). In Kubernetes 1.33, the default enforcement mode has been updated to apply the baseline profile to all namespaces unless explicitly overridden.

For production workloads, target the restricted profile wherever possible. This means running containers as non-root users, dropping all capabilities, using read-only root filesystems, and requiring seccomp profiles. Many containerized applications require minimal changes to comply with the restricted profile — the blockers are usually undocumented assumptions about filesystem write access or network binding capabilities that surface during testing.

Network Policies

By default, Kubernetes allows unrestricted communication between all pods in a cluster. Network Policies implement microsegmentation — allowing you to specify which pods can communicate with which other pods, on which ports, using which protocols. Without Network Policies, a compromised pod can reach any other service in the cluster, including control plane components and secrets stores.

Implementing a default-deny NetworkPolicy that blocks all ingress and egress traffic, then explicitly allowing only the necessary connections, is the most effective approach. This requires careful mapping of your application’s actual network dependencies — a discovery process that often reveals unexpected connections that should not exist. The discovery cost is worthwhile: organizations that implement default-deny network policies report dramatically reduced blast radius when container compromises occur.

Secrets Management

Kubernetes Secrets stored in etcd are base64-encoded by default — not encrypted. Any principal with etcd access or the ability to read Secrets in the target namespace can obtain secret values. Enabling encryption at rest for etcd using an external KMS (AWS KMS, Google Cloud KMS, or HashiCorp Vault) provides genuine protection for stored secrets.

For runtime secrets injection, avoid environment variables — they are visible to any process running in the container, appear in crash dumps, and are frequently included in debug logs. Mount secrets as volumes with restrictive permissions, or use a sidecar-based secrets injection pattern where secrets never appear in the pod spec at all. External Secrets Operator and Vault Agent Injector are the mature options in this space.

Supply Chain Security

The container image supply chain is a critical attack surface that many organizations secure inadequately. Images should be scanned for known vulnerabilities before admission to production environments — this is baseline hygiene. Image signing and verification using Sigstore/Cosign ensures that only signed images from trusted registries can run in your cluster. Policy engines like Kyverno or OPA Gatekeeper enforce these requirements at admission time.

Base image pinning — using SHA256 digests rather than mutable tags like “latest” — prevents supply chain attacks that compromise images after your initial security review. Pin your base images and implement a regular update cadence for rotating to patched versions, rather than relying on mutable tags that provide no integrity guarantee.

Monitoring and Runtime Detection

Falco remains the standard for runtime security monitoring in Kubernetes environments. Its rule library covers the most common attack patterns — unexpected outbound connections, privilege escalation attempts, sensitive file access, and process execution anomalies. Integrating Falco alerts into your security operations center creates a detection layer that complements the preventive controls described above.

Security hardening is not a one-time project. Cluster configurations drift as applications evolve and teams make expedient choices under time pressure. Regular automated compliance scanning against a defined baseline — using tools like kube-bench for CIS benchmark compliance — catches configuration drift before it becomes a security incident. Service mesh misconfiguration represents a critical but often overlooked attack vector in Kubernetes environments; our analysis of service mesh lateral movement documents how attackers exploit this surface. Earlier Kubernetes vulnerability research covers the ingress layer specifically — see our breakdown of critical Ingress-Nginx vulnerabilities and CVE-2026-24512.

Derek Schmidt📍 Washington, D.C., USA

Cybersecurity Editor and former NSA contractor with TS/SCI clearance. Covers nation-state threat actors, critical infrastructure protection, and U.S. cyber policy for NovVista's Washington bureau.

More by Derek Schmidt →