Kubernetes has become the de facto standard for container orchestration. But with power comes complexity—and security blind spots that attackers eagerly exploit. Here are seven vulnerabilities that catch even experienced teams off guard.
1. Overly Permissive RBAC
The Problem: Many teams start with cluster-admin access for convenience and never tighten it. Others grant broad permissions because RBAC is complex to configure correctly.
The Risk: One compromised pod with excessive permissions can access secrets across namespaces or even take over the cluster.
The Fix: Audit RBAC regularly. Apply least privilege. Use tools like kubectl-who-can to understand actual permissions.
2. Exposed Kubernetes Dashboard
The Problem: The Kubernetes dashboard is convenient but frequently exposed to the internet, sometimes without authentication.
The Risk: Full cluster access for anyone who finds it. Tesla's cryptomining incident started with an exposed dashboard.
The Fix: Never expose the dashboard publicly. Use kubectl proxy for local access. Require strong authentication.
3. Missing Network Policies
The Problem: By default, Kubernetes allows all pod-to-pod communication. Most teams never implement network policies to restrict this.
The Risk: An attacker who compromises one pod can freely access others, moving laterally through your cluster.
The Fix: Implement default-deny policies. Explicitly allow only required communication paths.
4. Secrets Stored Unencrypted
The Problem: Kubernetes secrets are base64-encoded, not encrypted. etcd stores them in plaintext by default.
The Risk: Anyone with etcd access or backup access can read all your secrets—API keys, database passwords, certificates.
The Fix: Enable encryption at rest for etcd. Use external secret managers (HashiCorp Vault, AWS Secrets Manager). Avoid mounting secrets as environment variables.
5. Running Containers as Root
The Problem: Many container images run as root by default. Teams often don't configure security contexts to prevent this.
The Risk: Container escapes become much more dangerous when the container process is root. Privilege escalation paths multiply.
The Fix: Set runAsNonRoot: true in security contexts. Use Pod Security Standards or admission controllers to enforce this.
6. Unscanned or Outdated Images
The Problem: Teams pull images from public registries without scanning them, or run images with known vulnerabilities because updating is inconvenient.
The Risk: Known CVEs in your base images are low-hanging fruit for attackers.
The Fix: Implement image scanning in CI/CD. Block deployment of images with critical vulnerabilities. Automate base image updates.
7. Inadequate Audit Logging
The Problem: Kubernetes audit logging is often disabled or not configured to capture useful events. When incidents occur, there's no trail to investigate.
The Risk: You won't know you've been compromised until it's too late. Forensics become impossible.
The Fix: Enable audit logging. Forward logs to a SIEM. Set up alerts for suspicious activities (secrets access, RBAC changes, exec into pods).
Your Kubernetes Security Checklist
- [ ] RBAC follows least privilege principle
- [ ] Dashboard is not publicly exposed
- [ ] Network policies restrict pod-to-pod traffic
- [ ] Secrets are encrypted at rest
- [ ] Containers run as non-root
- [ ] Images are scanned before deployment
- [ ] Audit logging is enabled and monitored
Secure Your Kubernetes Environment
Kubernetes security isn't a one-time setup—it's an ongoing practice. Many of these vulnerabilities exist because security was deferred in favor of shipping features. Need a comprehensive security review of your Kubernetes infrastructure? Our team can help identify and remediate vulnerabilities.