When we analyze Kubernetes cluster security posture, the finding distribution is remarkably consistent. Across 500+ clusters we have reviewed, the same seven misconfiguration patterns appear repeatedly — often in clusters that have otherwise mature security practices. That consistency is useful: it means there is a well-defined checklist that catches most of the actual risk before it becomes an incident.

These are the seven patterns, ranked by frequency in our dataset, with notes on automated detection for each.

1. Privileged Containers Running Outside System Namespaces (Found in 67% of Clusters)

A container running with privileged: true in its SecurityContext has essentially unrestricted access to the host kernel. It can modify kernel parameters, access all host devices, and in many environments mount the host filesystem. This is a container escape vector — a compromised privileged container is, for practical purposes, a compromised host node.

The reason this appears so frequently is not ignorance of the risk. It is that privileged containers often get created legitimately — for monitoring agents, for log collectors, for drivers — and then the pattern spreads. Engineers copy the SecurityContext from a working example without understanding that privileged: true was included because the specific monitoring agent required host access, not because it is generally necessary.

Detection: Scan all PodSpecs in the cluster for spec.containers[*].securityContext.privileged: true outside of system namespaces (kube-system, monitoring). Runtimekindle's manifest scanner flags this as HIGH severity in non-system namespaces. The fix is almost always to remove the privileged flag and add only the specific Linux capabilities the container actually needs — most monitoring agents need SYS_PTRACE at most, not full privilege.

2. Missing or Overpermissive NetworkPolicies (Found in 72% of Clusters)

Kubernetes has no default network isolation between pods. Without explicit NetworkPolicy objects, any pod in the cluster can make TCP connections to any other pod on any port. In practice, this means a compromised workload in a development namespace has the same network access to your production database as your production API service does.

The 72% figure is actually an undercount of the real risk — even clusters that have some NetworkPolicies often have them only on specific namespaces, leaving others with full flat-network access. The meaningful metric is not "has any NetworkPolicy" but "has default-deny NetworkPolicies covering all non-system namespaces."

Detection: Check each namespace for a NetworkPolicy that selects all pods and denies all ingress/egress with no exception rules. Absence of that baseline policy in a namespace means it is operating with a flat network. Automated tools including Runtimekindle's CSPM module will enumerate unprotected namespaces and flag them. Remediation requires writing default-deny policies and then explicitly allowlisting the actual communication requirements for each service — which requires knowing what those requirements are, typically from network flow logs or service mesh telemetry.

3. Exposed Kubernetes API Server (Found in 29% of Clusters)

The Kubernetes API server should not be accessible from the public internet without strong authentication controls. In 29% of the clusters we've reviewed, the API server was either directly internet-accessible or accessible from broader network segments than required. Of those, 41% had no network-level controls in addition to the Kubernetes authentication mechanisms — relying entirely on credentials to prevent unauthorized access.

This matters because the API server is the control plane. Authenticated API server access with cluster-admin permissions is a cluster compromise. Even lower-privileged API server access can be used to enumerate running workloads, query secrets, or find overpermissive ServiceAccounts to escalate through.

Detection: Check the API server's --advertise-address and whether the API server endpoint is reachable from external networks using a network access test. For managed Kubernetes (EKS, GKE, AKS), check whether the public API server endpoint is enabled and whether authorized networks are configured. All three major cloud providers offer private cluster configurations that disable public API server access entirely — prefer that configuration for production clusters. If public access is required for operational reasons, restrict it to known IP ranges and enforce MFA for cluster administrators.

4. Hardcoded Secrets in ConfigMaps and Environment Variables (Found in 54% of Clusters)

Kubernetes Secrets are not actually encrypted at rest by default — they are base64-encoded, which provides zero security. But even teams that understand this and use external secrets managers (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) often have hardcoded credentials in ConfigMaps, plain-text environment variable definitions in Deployments, or credentials in init container command arguments.

We find hardcoded secrets in 54% of clusters. In 18% of those cases, the secrets are database credentials for production databases. That number should be alarming — a credential in a ConfigMap or Deployment spec is readable by anyone with kubectl get access to that namespace, which in many clusters includes all developers.

Detection: Scan all ConfigMaps, Secrets, and Deployment/StatefulSet specs for patterns that match common secret formats: AWS access key prefixes (AKIA[A-Z0-9]{16}), private key headers (BEGIN RSA PRIVATE KEY), connection string formats (postgres://, mongodb+srv://). Runtimekindle's secrets detection runs this scan against your manifest repository and cluster state, not just against source code. Findings in cluster state indicate credentials that are already deployed, not just committed — a distinction that matters for remediation priority.

5. Missing Resource Limits Enabling Denial-of-Service Conditions (Found in 61% of Clusters)

This one is often filed under "reliability issue" rather than "security issue," but resource limits have a direct security implication: without them, a single compromised or misbehaving container can consume all available CPU and memory on a node, causing other workloads to fail. This is a denial-of-service vector that does not require any network access or privilege escalation — it just requires a container that is not bounded in its resource consumption.

More specifically, the attack scenario that concerns us is a cryptomining payload deployed in a compromised container. Without resource limits, the payload can run at 100% CPU indefinitely without triggering any resource-based alert. With limits set, the container gets throttled and the anomaly shows up in both resource metrics and in Runtimekindle's runtime behavior detection as unexpected process activity.

Detection: Check all running Pods for containers without resources.limits.cpu and resources.limits.memory set. Admission controller policies (Kyverno, OPA/Gatekeeper) can enforce that all new workloads include resource limits at deploy time. Retrofitting limits on existing workloads requires profiling actual usage first — setting limits below actual steady-state usage will cause OOMKill events or CPU throttling that affects application performance.

6. Overpermissive RBAC Roles and ClusterRoleBindings (Found in 58% of Clusters)

RBAC misconfiguration is the misconfiguration category with the most variation in how it manifests. We see it as: developers with cluster-admin ClusterRoleBindings because that was simpler than writing a minimal Role, ServiceAccounts with wildcard resource access (resources: ["*"]), and automated CI/CD pipelines with permissions to create new RoleBindings (which allows privilege escalation by creating a binding that grants itself more permissions).

The most dangerous pattern is a ServiceAccount that can modify RBAC resources. A compromised workload with that permission can grant itself cluster-admin and proceed from there. In our dataset, 12% of clusters have at least one non-system ServiceAccount with the ability to create or modify ClusterRoleBindings.

Detection: Audit RBAC using kubectl auth can-i --list for each ServiceAccount, or use automated tools that enumerate all effective permissions including those inherited through RoleBindings and ClusterRoleBindings. Look specifically for: ability to create/update RBAC resources, ability to list or get secrets cluster-wide, ability to exec into running pods. Each of those is an escalation or exfiltration vector from a compromised service account.

7. Containers Without Seccomp Profiles (Found in 79% of Clusters)

Seccomp (Secure Computing Mode) is a Linux kernel feature that allows you to restrict the system calls a container can make. Without a seccomp profile, a container can call any system call supported by the kernel — including system calls that are components of known container escape techniques.

The default Kubernetes behavior prior to version 1.27 was no seccomp profile applied. In Kubernetes 1.27+, the RuntimeDefault profile is applied by default to new pods, but existing deployments on older clusters retain the unrestricted configuration. In our dataset of clusters, 79% had containers without any seccomp profile — the highest-frequency finding across all seven categories.

The good news is that the RuntimeDefault seccomp profile blocks approximately 300 system calls that a typical web application never needs, including several documented in container escape techniques without breaking any common application workloads. Adding it is usually a zero-impact change for applications that have not been explicitly tested against a no-seccomp baseline.

Detection: Check all running containers for securityContext.seccompProfile.type. Absence or type: Unconfined is a finding. Apply type: RuntimeDefault across all workloads as a baseline, then evaluate whether any workloads require the more permissive Localhost profile for specific system call access.

Catching These Automatically

All seven of these misconfigurations are detectable with automated scanning, and all seven can be enforced at admission time with policy-as-code. That is the goal of Runtimekindle's Kubernetes security module: not just to find these patterns in existing clusters, but to prevent them from appearing in the first place by encoding the correct configuration as admission policies that block non-compliant manifests before they deploy.

The detection-to-enforcement pipeline looks like this: scan identifies current misconfigurations, generates a prioritized remediation list, and produces draft Kyverno or OPA/Rego policies for each pattern. The policies can be deployed in audit mode first — logging violations without blocking — to understand the scope before enforcing. Most teams move from audit to enforce mode within 2–3 sprints for each policy, after working through the exceptions in their existing workload inventory.

None of these misconfigurations are obscure or exotic. They are the standard failure modes of Kubernetes security, documented in CISA advisories, NSA hardening guides, and CIS Kubernetes Benchmark assessments. The reason they persist is not lack of knowledge — it is the gap between knowing what good looks like and having automated enforcement that makes the correct configuration the default. That enforcement gap is exactly what policy-as-code closes.