Kubernetes: 7 critical vulnerabilities we find in audits

Kubernetes is powerful but complex

Kubernetes orchestrates containers at scale, but its configuration surface is massive. A misconfigured cluster gives an attacker the ability to pivot between services, exfiltrate secrets, and compromise the entire infrastructure. Here are the seven flaws we find most often.

1. Pods running in privileged mode

A pod with privileged: true or hostPID: true has access to the host system. If an attacker compromises the application in this pod, they escape the container and access the node. From there, they can pivot to other pods in the cluster.

Check: kubectl get pods -o json | jq '.items[].spec.containers[].securityContext'

Fix: enforce Pod Security Standards in restricted mode. No application pod should be privileged.

2. Kubernetes secrets in base64, not encrypted

Kubernetes secrets are base64-encoded by default, not encrypted. Anyone with read access to secrets in the namespace can decode them. kubectl get secret db-creds -o jsonpath='{.data.password}' | base64 -d displays the password in plaintext.

Fix: enable encryption at rest for secrets with a KMS provider. Or use an external secrets manager (Vault, AWS Secrets Manager) with a dedicated operator.

3. Overly permissive RBAC

ClusterRoleBindings that give cluster-admin to application service accounts. Or roles with wildcards: resources: ["*"], verbs: ["*"]. A simple microservice's service account has permissions to delete entire namespaces.

Fix: apply the least privilege principle. Each service account should only have the exact permissions it needs within its namespace.

4. No network policies

By default, all pods in a Kubernetes cluster can communicate with each other. If an attacker compromises a frontend pod, they can directly access the database pod without going through the API. The absence of network policies is the equivalent of a flat network without segmentation.

Fix: implement NetworkPolicies that only allow necessary traffic. Start with a deny-all policy then add exceptions.

5. API server exposed without authentication

The Kubernetes API server accessible from the internet with anonymous authentication enabled. Or a Kubernetes dashboard exposed without authentication. This is the most direct open door to total cluster compromise.

Check: test curl -k https://[cluster-ip]:6443/api/v1/namespaces from outside.

Fix: disable anonymous access, restrict API server access by network, use OIDC authentication.

6. Container images with known vulnerabilities

Images based on outdated distributions with unpatched critical CVEs. latest images that change without control. Images from unverified public registries.

Fix: scan images in your CI/CD with Trivy or Grype. Use distroless or scratch images when possible. Pin versions with digests.

7. Service account token mounting

By default, every pod receives a service account token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. If the pod is compromised, the attacker uses this token to query the Kubernetes API with the service account's permissions.

Fix: disable automatic mounting with automountServiceAccountToken: false for pods that don't need it. Use projected tokens with limited lifetimes.

The audit approach

At CleanIssue, we review the configuration of each namespace, RBAC rules, network policies, and security contexts. Request your audit call to identify flaws in your cluster.