How to Secure Kubernetes Dashboards and Cluster Credentials on AWS
Retrospective: this article looks back at events from February 2018, written in 2026 with the benefit of hindsight.
An exposed Kubernetes dashboard gave attackers a path into Tesla's cloud in 2018. Here is how to secure Kubernetes management interfaces and cluster credentials on Amazon EKS.
Step 1: Don't expose the dashboard
The legacy Kubernetes Dashboard is rarely needed. If you use it, keep it internal and require authentication. Prefer the EKS console or tools that use your normal AWS identity.
Step 2: Restrict the API server endpoint
EKS clusters can have a public endpoint, a private endpoint, or both. For production:
- Enable the private endpoint.
- Disable public access, or restrict it to known CIDR ranges.
Step 3: Use AWS identity for cluster access
Manage who can access the cluster through EKS access entries mapped to IAM roles, rather than shared kubeconfig credentials. Grant the minimum Kubernetes permissions each role needs.
Step 4: Remove cloud keys from workloads
Pods should never contain AWS access keys. Use EKS Pod Identity or IAM Roles for Service Accounts (IRSA) so each workload gets short-lived credentials limited to what it needs.
Step 5: Limit node permissions
Restrict the node instance role and block pods from reaching the instance metadata service when they don't need it (require IMDSv2 with a hop limit of 1).
Step 6: Turn on detection
Enable GuardDuty EKS Protection and Runtime Monitoring to detect crypto mining, privilege escalation and suspicious API activity in clusters.
Common mistakes
- Development clusters with public endpoints and broad permissions, later promoted to production.
- Cluster-admin bindings granted to service accounts "temporarily."