E-EKS
eksctl
Official CLI for creating and managing Amazon EKS clusters, used to enumerate cluster and node-group configuration.
OVERVIEW
eksctl (github.com/eksctl-io/eksctl) is the official, AWS-endorsed CLI for creating and managing Amazon EKS clusters, and while its primary job is provisioning, its inspection subcommands (`eksctl get cluster`, `eksctl get nodegroup`, `eksctl get iamidentitymapping`) are exactly what a cloud pentester needs to understand how a cluster is wired into the rest of the AWS account.
The `aws-auth` ConfigMap it manages — mapping IAM users and roles to Kubernetes RBAC identities — is a frequent source of cluster-admin over-grants, and eksctl surfaces that mapping directly instead of requiring a raw `kubectl get configmap aws-auth -o yaml` decode.
USE CASES
Practical use cases
- 01
Enumerating EKS clusters and their versions, endpoint access settings, and networking config.
- 02
Listing node groups to check instance types, IAM instance-profile roles, and scaling configuration.
- 03
Reviewing the aws-auth IAM-to-RBAC identity mapping for over-privileged IAM principals.
- 04
Checking whether cluster API endpoint access is public, private, or both before planning further testing.
QUICK START
Once an AWS account with EKS clusters is in scope, to inspect cluster configuration, node groups, and IAM-to-Kubernetes identity mappings.
- Confirm the AWS account and its EKS clusters are inside the agreed scope.
- Install eksctl and the AWS CLI, and configure credentials for the scoped assessment identity.
- Run `eksctl get cluster --region <region>` to enumerate clusters in scope.
- Run `eksctl get iamidentitymapping --cluster <name>` to review the IAM-to-RBAC mapping for over-broad grants.
eksctl get iamidentitymapping --cluster my-cluster --region us-east-1BEFORE YOU RUN IT
What to check before running it
eksctl calls go through the AWS API and are logged in CloudTrail like any other AWS CLI activity — same credential and logging agreements apply.
eksctl is read-heavy for assessment use, but it can also create/modify/delete clusters and node groups — stick to `get`/`utils` subcommands unless changes are explicitly in scope.
IAM-to-RBAC mapping alone doesn't show what a mapped role can actually do inside Kubernetes — pair it with a Kubernetes RBAC review (kubectl auth can-i) for the full picture.