k8scan
Blog

Top 10 Kubernetes Security Misconfigurations & How to Fix Them

July 3, 2026 · 8 min read

Kubernetes security is hard. With hundreds of configuration options across pods, RBAC, network policies, and secrets, it's easy to accidentally leave a door open. In this post, we cover the 10 most common Kubernetes misconfigurations, why they matter, and how to detect them automatically using k8scan, a Kubernetes security scanner.

1. Privileged Containers

The most dangerous misconfiguration: a container with privileged: true has unrestricted access to the host kernel. An attacker who gains code execution inside a privileged container can escape to the host node trivially using nsenter or by mounting the host filesystem.

Remediation:

securityContext:
  privileged: false
  capabilities:
    drop: ["ALL"]
    add: ["NET_BIND_SERVICE"]  # only what's needed

k8scan detects this as K8S-001 (CRITICAL) and generates a PoC command showing the exact container escape path. It also correlates this finding in the Container Isolation Capability Break (CB-001).

2. Wildcard RBAC Permissions

ClusterRoles or Roles using verbs: ["*"] and resources: ["*"] grant unrestricted access to all resources. This is the RBAC equivalent of giving root to every service account. Attackers who compromise a pod with such permissions can exfiltrate secrets, create backdoor admin users, and deploy malicious workloads.

k8scan flags these as K8S-020 (CRITICAL) and includes them in the RBAC Boundary Break analysis. The recommended fix is to replace wildcards with explicit resource and verb lists following least-privilege principles.

3. Secrets in Environment Variables

Hardcoding AWS access keys, GitHub tokens, or database passwords in environment variables is alarmingly common. These credentials are visible to anyone with kubectl describe pod access and can leak through logs, debugging endpoints, or compromised containers.

k8scan's secrets scanner detects 30+ credential patterns (AWS keys, GitHub tokens, Google API keys, private keys, generic passwords) in both plain text and base64-encoded values. Use Kubernetes Secrets or an external secrets manager instead.

4. Missing Network Policies

By default, Kubernetes allows all pod-to-pod communication across the entire cluster. Without NetworkPolicy resources, an attacker who compromises one pod can reach every other pod, including control plane components and databases.

k8scan reports this as K8S-050 (HIGH) and recommends enforcing least-privilege network segmentation per namespace. A deny-all default policy followed by selective allow rules is the recommended approach.

5. Dangerous Linux Capabilities

Capabilities like SYS_ADMIN, BPF, NET_RAW, and SYS_PTRACE grant low-level kernel access that can be abused for container escape. SYS_ADMIN in particular is effectively equivalent to running as privileged.

k8scan identifies dangerous capabilities as K8S-005 (CRITICAL for SYS_ADMIN/ALL, HIGH for others). The fix: drop all capabilities and add back only what each container explicitly needs.

6. Host Namespace Sharing (hostPID / hostIPC / hostNetwork)

Pods that share the host's PID, IPC, or network namespaces break container isolation. hostPID: true allows a container to see all host processes, making credential theft and process injection trivial.

k8scan flags these with K8S-011 through K8S-013. These findings feed directly into the Container Isolation Break capability boundary check.

7. Docker / Containerd Socket Mounts

Mounting /var/run/docker.sock or /run/containerd/containerd.sock into a pod gives the container direct access to the container runtime. From there, an attacker can create new privileged containers, access all images, and take over the host node.

k8scan's K8S-014 (CRITICAL) check detects dangerous hostPath mounts including socket files, /etc, /proc, and /sys.

8. Anonymous API Server Access

If the API server has --anonymous-auth not explicitly set to false, unauthenticated requests are accepted. Combined with RBAC bindings to system:anonymous, this can give anyone on the network full cluster access without credentials.

k8scan checks for this as a control plane vulnerability and links it to the Cluster Access Boundary Break chain.

9. Using :latest Image Tags

Containers using :latest or no image tag receive unpredictable updates that can introduce breaking changes or new vulnerabilities. In a production security context, you can't verify what version is actually running.

k8scan detects this as K8S-008 (MEDIUM). Pin images to specific tags or SHA256 digests for reproducible and auditable deployments.

10. Missing Resource Limits

Containers without CPU and memory limits can cause denial-of-service by exhausting node resources. While not a direct security vulnerability, this is a workload hygiene issue that k8scan tracks in K8S-006 (MEDIUM).

Configure resources.limits.cpu and resources.limits.memory on every container, and set appropriate requests for scheduling.

How k8scan Automates Misconfiguration Detection

k8scan is a read-only Kubernetes security scanner purpose-built to detect these misconfigurations automatically. It runs 123+ checks across 8 categories, then correlates individual findings into Capability Breaks and multi-stage attack paths.

What sets k8scan apart from other tools is its attack path modeling. It doesn't just give you a list of findings — it tells you which combinations of misconfigurations create an exploitable attack chain, complete with Proof-of-Concept commands, MITRE ATT&CK mapping, and interactive attack graphs.

k8scan works as a single static binary (no runtime dependencies), supports 5 output formats, and integrates with GitHub Actions and GitLab CI. It's completely read-only — safe for production clusters.

Scan Your Cluster for These Misconfigurations

Upload your Helm chart or use the CLI to detect all 10 misconfigurations and more — in seconds.