Kubernetes security: common mistakes in AKS, EKS and GKE clusters

Managed services like Azure AKS, Amazon EKS and Google GKE run the Kubernetes control plane for you. What runs inside the cluster, and who can reach it, is still your responsibility. These are the mistakes we see most often.

1. Public API servers

The cluster API endpoint reachable from the whole internet, protected only by credentials. Fix: use private endpoints or restrict access to known IP ranges.

2. Over-broad RBAC

cluster-admin granted to developers, CI pipelines or service accounts that don't need it. Watch for permissions to create pods, read secrets or impersonate users: each can lead to full cluster control. Fix: namespace-scoped roles with least privilege, reviewed regularly.

3. Privileged and root containers

Pods running as root, with privileged: true, host networking or host path mounts. A compromised container like that can often escape to the node. Fix: enforce the Kubernetes Pod Security Standards (at least "baseline", ideally "restricted") with Pod Security Admission or a policy engine.

4. Default service account tokens everywhere

Every pod gets a service account token mounted by default, even when it never talks to the Kubernetes API. Fix: set automountServiceAccountToken: false unless needed, and give each workload its own service account.

5. No network policies

By default, every pod can talk to every other pod. One compromised service can reach your databases and internal APIs. Fix: default-deny network policies, then allow only the traffic each service needs.

6. Secrets handled loosely

Kubernetes Secrets are only base64-encoded, not encrypted, unless encryption at rest is configured. They're also often baked into images or manifests in Git. Fix: enable encryption at rest and use your cloud's secret manager through the Secrets Store CSI driver or a similar integration.

7. Cloud identity overreach

Node or workload identities with broad cloud permissions, so a compromised pod can read storage accounts or S3 buckets across the subscription. Fix: per-workload identity (Azure Workload Identity, EKS Pod Identity or IRSA, GKE Workload Identity) with narrow permissions.

We assess clusters as part of our IaC reviews and cloud penetration tests, including Helm charts and manifests before deployment. Request a quote.