All posts

The cluster was dead until I remembered I had AWS CLI in my terminal

Kubernetes access through AWS CLI is fast, secure, and reliable—if you set it up right. The trick is cutting through the noise and going straight to the commands and configs that work every time. Too many guides bury you in concepts. You just want kubectl talking to your EKS cluster in under five minutes. Here’s how to make it happen. First, confirm that your AWS CLI is installed and configured with the right AWS account. Run: aws sts get-caller-identity You should see your account ID. If no

Free White Paper

Just-in-Time Access + AWS IAM Policies: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

Kubernetes access through AWS CLI is fast, secure, and reliable—if you set it up right. The trick is cutting through the noise and going straight to the commands and configs that work every time. Too many guides bury you in concepts. You just want kubectl talking to your EKS cluster in under five minutes. Here’s how to make it happen.

First, confirm that your AWS CLI is installed and configured with the right AWS account. Run:

aws sts get-caller-identity

You should see your account ID. If not, fix your credentials before you do anything else.

Next, you’ll pull down the kubeconfig for your EKS cluster. AWS CLI makes this straightforward:

aws eks update-kubeconfig --name <cluster_name> --region <region>

This command edits your kubeconfig file locally, sets the correct context, and uses your IAM credentials to handle Kubernetes API access. No manual certificate copying. No editing YAML by hand.

Continue reading? Get the full guide.

Just-in-Time Access + AWS IAM Policies: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Right after this, check your access:

kubectl get nodes

If you see your nodes listed, you have AWS CLI Kubernetes access set up. If you get permission errors, make sure your IAM role or user has eks:DescribeCluster and the right Kubernetes RBAC role bindings.

A common pitfall is misaligned IAM permissions. The AWS CLI side can succeed, but Kubernetes can still reject you if RBAC is missing. Map your IAM entities to Kubernetes users or groups inside the aws-auth ConfigMap:

kubectl edit configmap aws-auth -n kube-system

Add your IAM role or user under mapRoles or mapUsers. This is where AWS CLI authentication meets Kubernetes authorization. Both need to pass for full access.

From there, AWS CLI becomes your central control point for Kubernetes credentials. Rotate IAM keys, not random kubeconfigs. Re-run aws eks update-kubeconfig whenever you switch accounts or clusters. Context switching is as simple as:

kubectl config use-context <context_name>

This way, AWS CLI manages identity, and Kubernetes stays clean. No sprawl of expired tokens. No stale kubeconfigs.

If you want to see what this could look like automated end-to-end, without touching a single YAML, you can watch it live at hoop.dev and have AWS CLI Kubernetes access in minutes.

Get started

See hoop.dev in action

One gateway for every database, container, and AI agent. Deploy in minutes.

Get a demoMore posts