7 Min. Read<\/p>\n
Your DevOps team has just set up the first production cluster, the microservices are running, and the CISO is asking for the security concept. The answer usually falls short. Because most Kubernetes breaches don’t happen through sophisticated zero-day exploits, but through misconfigurations that can be fixed in less than an hour. Knowing the eight most common mistakes lets you harden your cluster in five working days.<\/strong><\/p>\n Kubernetes is complex. A single cluster comes with several hundred configuration parameters, spread across Pods, Services, Network Policies, RBAC roles, and Admission Controllers. The risk lies in this complexity: It’s not the attacker exploiting a new vulnerability, but the administrator overlooking a default setting, who opens the door.<\/p>\n The numbers are clear. According to the Red Hat State of Kubernetes Security Report 2024, 90 percent of all surveyed organizations with Kubernetes environments experienced at least one security incident in the past year. 46 percent reported concrete revenue or customer loss as a direct consequence. And 67 percent had to delay deployments because security concerns blocked the release.<\/p>\n The driver behind these numbers is the rapid spread of containers in production environments. According to the CNCF Annual Survey 2025, 56 percent of all organizations now run containers in production. In 2023, it was just 41 percent. With every new cluster, the attack surface grows when basic security configurations are not set from the start.<\/p>\n 90 %<\/p>\n of organizations with Kubernetes environments experienced at least one security incident in the past year.<\/p>\n 45 %<\/p>\n of all Kubernetes security incidents are caused by misconfigurations.<\/p>\n USD 4.3 million<\/p>\n average cost of a security incident caused by cloud misconfigurations, a 17 percent increase year-over-year.<\/p>\n Sources: Red Hat State of Kubernetes Security Report 2024, IBM Cost of a Data Breach Report 2025<\/p>\n<\/div>\n Gartner predicts that by 2026, 99 percent of all cloud security incidents will be the customer’s fault. The cloud providers are not the problem. It’s the teams that set up clusters without questioning the default configurations. The good news: Knowing the most common misconfigurations allows you to systematically eliminate them.<\/p>\n The following eight misconfigurations cover the majority of the real attack surface. Each can be addressed specifically without disrupting ongoing operations. The order is based on risk: the most dangerous misconfigurations come first.<\/p>\n Privileged Containers Without Restrictions<\/p>\n Containers running with the privileged flag have full access to the host kernel. An attacker who compromises such a container controls the entire node. Solution: Set Pod Security Standards to Baseline or Restricted. Only allow privileged containers for system workloads such as CNI plugins or monitoring agents, and isolate them in dedicated namespaces. Every pod running privileged without justification is an open door.<\/p>\n<\/div>\n<\/div>\n RBAC with cluster-admin on Default Service Accounts<\/p>\n The most dangerous RBAC misconfiguration: The ClusterRoleBinding cluster-admin is bound to the default service account of a namespace. Every pod in that namespace gains full cluster control. Solution: Never assign roles to default service accounts. Create dedicated service accounts per workload and assign only the minimum required permissions following the least-privilege principle. Audit existing bindings regularly.<\/p>\n<\/div>\n<\/div>\n Missing Network Policies<\/p>\n Without Network Policies, every pod can communicate with every other pod in the cluster. A compromised frontend pod can directly reach the database. In a cluster with dozens of services, a single compromised pod is enough to move laterally through the entire network. Solution: Set up a default-deny policy per namespace. Then selectively allow only the necessary connections. Start with namespaces that process sensitive data.<\/p>\n<\/div>\n<\/div>\n Secrets as Environment Variables Instead of Encrypted<\/p>\n Kubernetes Secrets are only Base64-encoded by default, not encrypted. Injecting secrets as environment variables into pods risks exposing them in logs, crash dumps, or process listings. Solution: Enable encryption at rest for etcd. Mount secrets via volumes instead of environment variables. For production-critical credentials, use an external secrets manager such as HashiCorp Vault, AWS Secrets Manager, or the External Secrets Operator integration.<\/p>\n<\/div>\n<\/div>\n Containers Running as Root<\/p>\n Many container images start processes as the root user by default. In the event of a container escape, the attacker gains root privileges on the host. The problem is widespread: many official images on Docker Hub run as root without explicit user configuration. Solution: Enable runAsNonRoot in the SecurityContext and set an explicit user ID. Use base images that work without root, such as Google’s Distroless images or Chainguard’s hardened images.<\/p>\n<\/div>\n<\/div>\n No Image Scanning in the CI\/CD Pipeline<\/p>\n According to the Sysdig Cloud-Native Security Report 2025, 87 percent of all container images in production contain critical or high vulnerabilities. The reason: teams use outdated base images without checking what has changed since the last build. Solution: Integrate image scanners like Trivy, Grype, or Snyk Container into your CI\/CD pipeline. Automatically block builds with critical CVEs. Regularly update base images and implement an allowlist process for approved registries.<\/p>\n<\/div>\n<\/div>\n Publicly Accessible Kubernetes API Server<\/p>\n A publicly accessible API server is an invitation for brute-force attacks on credentials and for exploiting known API vulnerabilities. Shodan scans regularly reveal thousands of publicly accessible Kubernetes API endpoints. Solution: Place the API server behind a VPN or bastion host. Restrict access to known IP ranges. Enable API audit logging to detect unusual access patterns. Use short-lived tokens instead of static credentials.<\/p>\n<\/div>\n<\/div>\n Missing Resource Limits and Requests<\/p>\n Without CPU and memory limits, a single pod can exhaust the resources of an entire node. This is not just a stability risk but also an entry point for denial-of-service attacks within the cluster. A cryptomining container that infiltrates through a compromised dependency can silently drain all computing power. Solution: Define resource requests and limits for every container. Set LimitRanges per namespace and configure ResourceQuotas.<\/p>\n<\/div>\n<\/div>\n<\/div>\n Since Kubernetes 1.25, the deprecated Pod Security Policies (PSP) have been removed. They are replaced by Pod Security Standards (PSS) with the built-in Pod Security Admission Controller. This defines three security levels enforced at the namespace level.<\/p>\n The Privileged level allows everything and is intended exclusively for system workloads such as kube-system pods and CNI plugins. Baseline prevents known privilege escalation paths and should serve as the absolute minimum for every namespace. Restricted enforces current pod hardening best practices and is the target for all workloads that don’t explicitly require elevated privileges.<\/p>\n Important: Don’t Delay PSP Migration<\/p>\n Organizations still running Kubernetes versions before 1.25 or using PSP configurations need to migrate promptly. The official Kubernetes documentation recommends first enabling the audit and warn modes of Pod Security Admission for all namespaces. This lets teams see which pods violate the desired policy without disrupting ongoing operations. Only when all workloads are compliant should the enforce mode be activated.<\/p>\n<\/div>\n Implementation is done via labels on the namespace. A single label is enough to activate the desired security level. Teams that have not yet implemented any pod security mechanisms should start with the Baseline level in audit mode and switch to enforce within four to six weeks.<\/p>\n Additionally, using policy engines like Kyverno or Open Policy Agent (OPA) with Gatekeeper is recommended. These enable finer control than the built-in Pod Security Standards and can enforce additional rules such as mandatory labels, image allowlists, or maximum replica counts. Falco, which now has more than 22 million downloads and is a CNCF Graduated project, provides complementary runtime security: it detects suspicious behavior in running containers in real time.<\/p>\n Day 1: Inventory and RBAC Audit<\/strong><\/p>\n Day 2: Activate Pod Security Standards<\/strong><\/p>\n Day 3: Network and Secrets<\/strong><\/p>\n Day 4: CI\/CD Integration and Image Hygiene<\/strong><\/p>\n Day 5: Monitoring, Alerting, and Documentation<\/strong><\/p>\n Kubernetes security is not a project you complete once and then forget. It’s an ongoing process that begins with an honest inventory. The eight misconfigurations described here cover the majority of the real attack surface. None of them requires a new tool or an external consulting project.<\/p>\n Start this week with the RBAC audit and activate Pod Security Standards in audit mode. Within five days, you’ll have a significantly hardened environment. The investment is five working days of focused effort. The return is not being among the 46 percent who lose revenue and customers after a Kubernetes security incident. And remember: security in Kubernetes is not a static state. Every cluster upgrade, every new dependency, and every additional namespace deserves a fresh look at the configuration.<\/p>\n Every question is locked. A tap unlocks the answer.<\/p>\n The most common risks are RBAC permission misconfigurations, privileged containers without restrictions, missing network policies, unencrypted secrets, and containers running as root. According to the Red Hat State of Kubernetes Security Report 2024, 45 percent of all Kubernetes security incidents are caused by misconfigurations, not by zero-day vulnerabilities or targeted attacks.<\/p>\n<\/details>\n Pod Security Standards (PSS) are a security mechanism built into Kubernetes since version 1.25 that replaces the deprecated Pod Security Policies. They define three security levels: Privileged for system workloads, Baseline as the minimum standard against known privilege escalation paths, and Restricted as best-practice hardening for all regular workloads. Enforcement is done via labels at the namespace level.<\/p>\n<\/details>\n The API server should not be publicly accessible. Place it behind a VPN or bastion host. Restrict access to known IP ranges and enable API audit logging. Additionally, assign RBAC permissions following the least-privilege principle and use short-lived tokens instead of long-term credentials.<\/p>\n<\/details>\n For image scanning, Trivy, Grype, or Snyk Container are suitable options. For runtime security, Falco and Sysdig provide real-time detection of suspicious activities in running containers. For policy enforcement, Kyverno and Open Policy Agent with Gatekeeper are proven solutions. These tools can be integrated into the CI\/CD pipeline so insecure configurations are detected before deployment.<\/p>\n<\/details>\n The basic hardening of a Kubernetes cluster can be implemented in five working days: RBAC audit, Pod Security Standards, Network Policies, Secrets Management, and CI\/CD integration. Fine-grained tuning and ongoing monitoring are a continuous process that should be integrated into regular operations. For organizations with multiple clusters, a centralized policy management through GitOps workflows is recommended.<\/p>\n<\/details>\n More from the MBF Media Network<\/p>\nKey Takeaways<\/h2>\n
\n
Why Misconfigurations Are the Biggest Kubernetes Risk<\/h2>\n
The 8 Most Common Misconfigurations and How to Fix Them<\/h2>\n
Pod Security Standards: The New Minimum Standard<\/h2>\n
Checklist: Harden Your Kubernetes Cluster in Five Days<\/h2>\n
\n
\n
\n
\n
\n
Conclusion: Start with the RBAC Audit<\/h2>\n
Frequently Asked Questions<\/h2>\n
What are the most common Kubernetes security risks?<\/strong><\/summary>\n
What are Pod Security Standards in Kubernetes?<\/strong><\/summary>\n
How do I secure the Kubernetes API Server?<\/strong><\/summary>\n
Which tools help with Kubernetes security?<\/strong><\/summary>\n
How long does it take to secure a Kubernetes cluster?<\/strong><\/summary>\n
Recommended Reading<\/h2>\n
\n