Kubernetes Security: Common Misconfigurations That Lead to Breaches

Kubernetes security breaches rarely happen because of zero-day vulnerabilities. They happen because of misconfiguration. After analyzing dozens of real-world Kubernetes compromises, certain patterns keep appearing.

Here are the mistakes that keep leading to breaches - and how to avoid them.

1. Exposed Kubernetes API Server

The Problem: The Kubernetes API server is the control plane's front door. Exposing it to the public internet without proper authentication is asking for trouble.

What Attackers Do:

• Scan the internet for exposed API servers (shodan.io makes this trivial)
• Attempt authentication bypass
• Exploit known API server vulnerabilities
• Use default or weak credentials

Real-World Example: In 2019, Tesla's Kubernetes dashboard was found exposed without authentication, allowing attackers to mine cryptocurrency using Tesla's infrastructure.

Fix:

• Never expose the API server directly to the internet
• Require strong authentication (client certificates, OIDC, etc.)
• Use network policies to restrict access
• Enable audit logging
• Consider a VPN or bastion host for administrative access

Check Your Config:

kubectl cluster-info

If the API server is accessible at a public IP without going through a VPN, you have a problem.

2. Privileged Containers

The Problem: Running containers with privileged: true gives them nearly unlimited access to the host system. It's the equivalent of running everything as root.

What Attackers Do: If they compromise a privileged container, they can:

• Access the host file system
• Load kernel modules
• Access other containers on the same node
• Pivot to compromise the entire cluster

Fix:

• Avoid privileged containers unless absolutely necessary
• Use Pod Security Standards to block privileged pods
• If you must use privileges, restrict specific capabilities instead

Audit:

kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.containers[].securityContext.privileged==true) | {name: .metadata.name, namespace: .metadata.namespace}'

3. Overly Permissive RBAC

The Problem: Default Kubernetes RBAC is often too permissive. Some organizations just grant cluster-admin to everyone to avoid dealing with permission issues.

What Attackers Do: Compromise a service account or user with excessive permissions, then use those permissions to:

• Access secrets across namespaces
• Create new privileged pods
• Modify cluster configuration
• Deploy backdoors

Fix: Follow least privilege:

• Grant only the minimum necessary permissions
• Use Role and RoleBinding (namespace-scoped) instead of ClusterRole and ClusterRoleBinding when possible
• Regularly audit RBAC assignments
• Don't grant cluster-admin unless truly necessary

Audit:

kubectl get clusterrolebindings -o json | jq -r '.items[] | select(.roleRef.name=="cluster-admin") | {name: .metadata.name, subjects: .subjects}'

4. Secrets Stored Insecurely

The Problem: Kubernetes secrets are base64-encoded by default, not encrypted. They're also often checked into version control or stored insecurely.

What Attackers Do:

• Extract secrets from compromised pods
• Pull secrets from exposed git repositories
• Access unencrypted etcd backups
• Retrieve secrets via the API with stolen credentials

Fix:

• Enable encryption at rest for secrets
• Use external secret management (Vault, AWS Secrets Manager, Azure Key Vault)
• Never commit secrets to version control
• Use sealed secrets or similar tools for GitOps
• Implement secret rotation
• Limit secret access with RBAC

5. No Network Policies

The Problem: By default, Kubernetes allows all pods to communicate with all other pods. If an attacker compromises one pod, they can laterally move to others.

What Attackers Do:

• Compromise a less-secured pod (maybe a legacy app)
• Scan the internal network for other services
• Move laterally to more valuable targets
• Exfiltrate data from databases and internal services

Fix: Implement default-deny network policies:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Then explicitly allow necessary traffic.

6. Exposed Dashboard

The Problem: The Kubernetes dashboard is powerful and, if exposed without proper authentication, allows complete cluster control.

What Attackers Do: Search for exposed dashboards, access them without authentication, and take over clusters.

Fix:

• Don't expose the dashboard to the internet
• Require authentication
• Use kubectl proxy for local access
• Consider not deploying the dashboard at all if you don't need it

7. Running as Root

The Problem: Many container images run processes as root by default. If the container is compromised, attackers have root privileges within the container.

What Attackers Do: Use root privileges to:

• Escape the container more easily
• Modify container internals
• Access sensitive files

Fix:

• Set runAsNonRoot: true in security contexts
• Specify a non-root user in Dockerfiles
• Use Pod Security Standards to enforce this

Example:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000

8. Not Using Pod Security Standards

The Problem: Kubernetes' built-in security controls (Pod Security Standards) aren't enabled by default in many clusters.

Fix: Enable and enforce Pod Security Standards:

• Privileged: Unrestricted, for trusted workloads
• Baseline: Minimally restrictive, prevents known privilege escalations
• Restricted: Heavily restricted, follows hardening best practices

Start with baseline in warn mode, work toward restricted in enforce mode.

9. Outdated Kubernetes Versions

The Problem: Kubernetes releases security patches regularly. Running old versions means running known vulnerabilities.

What Attackers Do: Exploit known CVEs in outdated Kubernetes versions.

Fix:

• Keep Kubernetes updated (at least quarterly)
• Subscribe to Kubernetes security announcements
• Test updates in non-production environments first
• Have a process for emergency patching

10. No Container Image Scanning

The Problem: Container images often contain vulnerabilities, outdated libraries, and sometimes malware.

What Attackers Do: Exploit known CVEs in base images or dependencies within containers.

Fix:

• Scan images before deployment
• Use minimal base images (alpine, distroless)
• Regularly rebuild images with updated dependencies
• Implement admission controllers to block vulnerable images

Tools:

• Trivy
• Clair
• Anchore
• Snyk Container

Putting It All Together

Kubernetes security isn't about implementing every possible control. It's about:

1. Visibility: Know what's running in your cluster
2. Least Privilege: Minimize permissions and capabilities
3. Defense in Depth: Layer controls so single failures don't lead to breaches
4. Monitoring: Detect anomalies and respond quickly

Start with these ten fixes. They'll eliminate the majority of common attack vectors and put you ahead of most Kubernetes deployments.

The cloud-native world moves fast, but security fundamentals haven't changed: reduce attack surface, follow least privilege, and assume breach.