Kubernetes and Container Security: The Misconfigurations We Keep Finding

Kubernetes and containers now run most new production workloads, but the security model shifts under them in ways that don't always get revisited, the assumption that "the cloud provider secures the cluster" leaves a large, genuinely exploitable surface entirely in the customer's hands. CISA and the NSA's joint Kubernetes Hardening Guidance exists precisely because this gap is common enough to warrant a dedicated federal advisory, not a rare edge case. These are the misconfigurations that show up most often when we actually test a cluster rather than review its configuration on paper.

Overly permissive RBAC and default service accounts

Kubernetes' role-based access control is powerful and, by default, permissive in ways teams don't always notice, a ClusterRoleBinding to cluster-admin granted early in a project for convenience has a way of never getting revoked. Pods that don't explicitly disable it get a default service account token mounted automatically, which is often enough on its own to enumerate the cluster's API and, depending on what else is misconfigured, escalate well beyond what that specific workload should ever need to touch.

Privileged containers and missing Pod Security controls

A container running with privileged: true, a mounted Docker socket, or hostPID/hostNetwork enabled effectively erases the isolation container security depends on, a compromise of that one workload becomes a compromise of the underlying node. Pod Security Admission (Kubernetes' built-in replacement for the deprecated PodSecurityPolicy) exists to block exactly this at the cluster level, but it has to actually be configured and enforced, its mere availability in a modern Kubernetes version doesn't do anything on its own.

Exposed or weakly authenticated API servers and dashboards

The Kubernetes API server, the kubelet's own API, and tools like the Kubernetes Dashboard have all shown up exposed to the internet with weak or default authentication in real assessments, and each one is a direct path to full cluster control, not a lesser finding. This is one of the first things worth checking, because it's also one of the fastest wins for anyone who finds it first.

Missing network policies

Kubernetes networking is flat by default, every pod can reach every other pod unless a NetworkPolicy says otherwise. Most clusters we see have never defined one, which means a single compromised, internet-facing workload has unrestricted network access to everything else in the cluster, including internal services that were never meant to be reachable from it.

Secrets in environment variables instead of a real secrets store

Kubernetes Secret objects are only base64-encoded, not encrypted, unless encryption at rest is explicitly configured, and secrets passed as plain environment variables are trivially readable by anyone who can exec into the pod or read its spec. A dedicated secrets manager (cloud-provider KMS-backed, or a tool like Vault) with proper access controls closes a gap that env-var secrets leave wide open.

What this means for testing

Most of these are configuration issues, not code vulnerabilities, which means they're exactly the kind of finding a properly scoped assessment catches and a generic vulnerability scan usually misses, since scanners typically check images and known CVEs, not RBAC bindings or pod security context. Our Cloud Security engagements include cluster configuration review alongside workload and image testing as standard scope, not an optional add-on. For the broader cloud misconfiguration patterns this sits alongside, see our companion piece on common cloud security misconfigurations. Kubernetes Secret objects are only base64-encoded, not encrypted by default, the same underlying problem we cover in hardcoded secrets in code, and a compromised pod reaching a cloud metadata endpoint is exactly the escalation path described in SSRF: the cloud-era vulnerability. None of this replaces checking what's inside the image itself before it ever runs, see our piece on container image scanning and software supply chain security.