Kubernetes Security: The 7 Most Common Misconfigurations in Production Systems

1 min Reading Time

Kubernetes has become the de facto standard for container orchestration. However, the system’s complexity creates a massive attack surface: misconfigured RBAC policies, exposed API servers, and privileged containers are more the rule than the exception in production environments. Seven errors that can be fixed immediately.

TL;DR

NSA/CISA: “Misconfiguration is the most common vulnerability in Kubernetes”
Over 380,000 publicly accessible Kubernetes API servers (Shadowserver 2024)
Red Hat Report: 67 percent of companies had a security incident in K8s
Most vulnerabilities are configuration errors – not software bugs

1-2: API Server Exposure and Missing RBAC

Error 1: API server publicly accessible. The Kubernetes API server is the brain of the cluster. Whoever has access controls everything. Nevertheless, scanners like Shodan find hundreds of thousands of publicly accessible API servers. Solution: Make the API server accessible only via VPN or Private Endpoint.

Error 2: Overprivileged RBAC roles. Cluster-admin for every developer because it’s “easier.” The principle of least privilege is often ignored in Kubernetes. Solution: Namespace-specific roles instead of ClusterRoles, regular RBAC audits with tools like rbac-police or kubectl-who-can.

3-4: Privileged Containers and Missing Network Policies

Error 3: Privileged containers. Containers running as root or with the privileged flag set can break out of the host system. A container escape gives the attacker access to the entire node. Solution: SecurityContext with runAsNonRoot, readOnlyRootFilesystem, and dropping all Linux capabilities.

Error 4: No network policies. Without network policies, any pod can communicate with any other pod. Lateral movement within the cluster is trivial. Solution: Default-deny policy for all namespaces, then explicit allow rules for necessary communication.

5-6: Secrets in Plaintext and Outdated Images

Error 5: Secrets as Base64 in etcd. Kubernetes secrets are only Base64 encoded, not encrypted. Anyone with access to etcd can read all secrets in plaintext. Solution: Enable encryption at rest for etcd or use external secret management solutions (Vault, AWS Secrets Manager, Azure Key Vault).

Error 6: Outdated container images. Images with known CVEs run in production for months because no one scans them. Solution: Image scanning in the CI/CD pipeline (Trivy, Snyk Container) and admission controllers (OPA Gatekeeper, Kyverno) that block insecure images.

7: Missing Pod Security Standards

Error 7: No pod security standards/admission. Since Kubernetes 1.25, Pod Security Standards (PSS) are the official successor to PodSecurityPolicy. Three levels: Privileged (everything allowed), Baseline (known escalation vectors blocked), Restricted (best practice). Many clusters still run without any restrictions.

Solution: Activate PSS in “warn” mode, identify and fix violations, then switch to “enforce.” For more complex policies: OPA Gatekeeper or Kyverno as admission controllers.

Key Facts

Exposed API Servers: 380,000+ publicly accessible (Shadowserver Foundation)

Security Incidents: 67 percent of K8s users had an incident (Red Hat 2024)

Image Vulnerabilities: On average, 72 known CVEs per container image (Sysdig 2024)

Frequently Asked Questions

How do I check my cluster for misconfigurations?

Tools: kube-bench (CIS Benchmark Check), kubescape (NSA/CISA Hardening Guide), Trivy (image + config scanning), rbac-police (RBAC audit). All open source and ready to use in minutes.

Is a managed Kubernetes (EKS, AKS, GKE) enough?

Managed K8s reduces the attack surface of the control plane, but the workload configuration (RBAC, network policies, pod security) remains the user’s responsibility. Most of the mentioned errors affect exactly this area.

What is the quickest win?

Network policies with default-deny. In most clusters, pod-to-pod communication is completely unrestricted. A single default-deny policy per namespace blocks lateral movement immediately – with minimal effort.

About the author: Alec Chizhik

Read article

Cloud-Sicherheit