Kubernetes Security Plagued by Human Error and Misconfigurations

This article is based on reporting originally published by SDxCentral, drawing on StackRox’s “State of Container and Kubernetes Security Report” (2020), conducted in partnership with 451 Research.

The Core Finding: Misconfiguration Outranks Vulnerabilities and Attacks

Securing a Kubernetes environment is a substantially harder problem than simply running one. A survey of more than 540 Kubernetes and container practitioners — spanning IT security, DevOps, engineering, and product roles — found that human error and misconfiguration are the dominant causes of container security incidents. The research was conducted by StackRox with assistance from advisory firm 451 Research.

Key top-line results from the report:

• 94% of respondents experienced at least one container security incident in the preceding 12 months.
• 44% reported that security concerns delayed moving applications into production.
• 61% cited misconfigurations as the risk they were most concerned about.
• 27% identified known vulnerabilities as their primary concern.
• 12% named active attacks as their top concern.

The near-universal rate of security incidents, combined with the production delays they cause, paints a picture of an ecosystem where security practices have not kept pace with adoption speed.

Why Kubernetes Is Especially Prone to Misconfiguration

Kubernetes offers an enormous surface area for configuration: pod security policies, RBAC rules, network policies, admission controllers, secrets management, service account permissions, and more. Each of these has sensible defaults that are often insecure, and each can be overridden by operators who may not fully understand the downstream security implications.

Common misconfiguration categories that create security exposure in Kubernetes clusters include:

• Overly permissive RBAC roles — granting cluster-admin to service accounts or users who do not require it.
• Running containers as root — failing to set securityContext.runAsNonRoot: true or a specific UID.
• Disabled or absent network policies — allowing unrestricted pod-to-pod and pod-to-external communication.
• Exposed Kubernetes API server — leaving the API server reachable from the public internet without strong authentication.
• Privileged containers — setting privileged: true without a clear operational justification.
• Missing resource limits — creating denial-of-service risk through unbounded CPU and memory consumption.
• Secrets stored in environment variables or ConfigMaps rather than a dedicated secrets manager.

As Michelle McLean, then VP of Marketing at StackRox, summarized: “People understand that Kubernetes has a lot of knobs and dials, and it’s easy to get it wrong.”

The Business Impact: Delayed Deployments and Slowed Innovation

The business case for Kubernetes is speed — faster build, test, and release cycles. When security incidents or security reviews block production deployments, that core value proposition erodes. The StackRox report identified the delayed rollout of applications as a direct consequence of unresolved security concerns, creating a feedback loop where rapid adoption outpaces the ability to govern what is being deployed.

This tension is not unique to Kubernetes, but the platform’s complexity amplifies it. Organizations that adopt cloud-native architecture without embedding security into their pipelines often discover gaps only at runtime — at which point the cost of remediation is significantly higher.

Shifting Security Left in Kubernetes Workflows

The report’s primary recommendation echoes a principle that has gained wide traction in DevSecOps: security must be embedded into the development and deployment pipeline rather than applied as an afterthought before or after production release.

Practically, shifting security left in a Kubernetes context means:

• Linting and policy checks at build time — tools such as kube-score, kube-linter, and Checkov can analyse Kubernetes manifests for security misconfigurations before they reach a cluster.
• Admission controllers — deploying policy engines such as Open Policy Agent (OPA) Gatekeeper or Kyverno to enforce security policies at the point of admission to the cluster.
• CI/CD pipeline integration — making security policy checks a blocking gate in CI, so a manifest with a privileged container or missing resource limits cannot be merged without explicit review.
• Developer education — providing developers with clear, opinionated baseline manifests and documented security requirements rather than expecting them to derive best practices independently.
• Runtime monitoring — using tools such as Falco to detect anomalous behaviour at runtime, complementing preventive controls.

Context: Kubernetes Security Audits and the CNCF Ecosystem

The report was published following the first formal security audit of Kubernetes, commissioned by the Cloud Native Computing Foundation (CNCF). That audit surfaced a number of architectural concerns and was intended to give the broader community a clearer picture of the platform’s attack surface. Despite that effort, widespread adoption continued to outrun security maturity across many organisations.

The StackRox findings reinforced a consistent message from the security community: the Kubernetes project itself is not the primary source of risk for most organisations. The risk lies in how clusters are configured and operated by the humans managing them.

Recommendations for Kubernetes Security Teams

Based on the themes in the StackRox report, teams looking to reduce misconfiguration risk should consider the following actions:

1. Audit existing clusters against a recognised benchmark such as the CIS Kubernetes Benchmark using tools like kube-bench.
2. Define and enforce a baseline pod security standard — Kubernetes 1.23+ ships with Pod Security Admission as a replacement for the deprecated PodSecurityPolicy.
3. Review RBAC configurations regularly — use kubectl auth can-i --list and third-party tools such as rbac-lookup or rakkess to audit effective permissions.
4. Enable and review audit logs — the Kubernetes API server audit log provides visibility into who is doing what in the cluster.
5. Implement a GitOps workflow — storing all manifests in version control and deploying through a controlled pipeline reduces ad-hoc manual changes that introduce misconfiguration.
6. Cross-train DevOps and security teams — misconfigurations often occur at the boundary between teams. Shared understanding of security requirements reduces the chance of errors.

As the report noted: “Companies need a combination of increased learning, cross-pollination, new tooling, and updated processes to identify and remediate security mistakes during build and deploy — rather than waiting for exposure during runtime.”

Summary

The StackRox “State of Container and Kubernetes Security” survey data from early 2020 identified a clear and persistent pattern: misconfiguration driven by human error is the leading source of security risk in Kubernetes environments, ahead of both unpatched vulnerabilities and external attacks. Addressing this requires a structural shift — embedding security into CI/CD pipelines, enforcing policy at admission time, and investing in cross-team education — rather than relying on reactive runtime detection alone.