Authenticate to Amazon EKS without Static Credentials

Authenticate to EKS clusters using AWS IAM and EKS Access Entries

Managing Kubernetes access with ConfigMap-based aws-auth entries is error-prone and hard to audit. Who has access? When was it granted? Long-lived kubeconfig tokens get shared across machines, and revoking access means editing a ConfigMap by hand.

EKS Access Entries provide a cleaner model: IAM principals map directly to Kubernetes permissions, and every authentication event is recorded in CloudTrail. Combined with Vouch, every kubectl command traces back to a hardware-verified human identity – no static tokens, no shared kubeconfigs.

How it works

The authentication flow chains three components:

vouch login --> vouch credential eks --> kubectl

1. vouch login – The developer authenticates with their YubiKey and receives an OIDC ID token from the Vouch server.
2. vouch credential eks – The CLI exchanges the OIDC token for temporary AWS STS credentials, then builds a presigned STS GetCallerIdentity URL with the x-k8s-aws-id header, base64url-encodes it, and outputs a Kubernetes ExecCredential JSON.
3. kubectl – The Kubernetes client sends the token to the EKS API server, which validates it against IAM and applies the permissions defined by Access Entries or RBAC.

Because every step uses short-lived credentials, there are no static kubeconfig tokens or long-lived AWS keys to manage. No AWS CLI installation is required – Vouch handles STS and EKS API calls natively.

Prerequisites

Before setting up EKS authentication with Vouch, ensure you have:

• Vouch CLI installed and enrolled – Complete the Getting Started guide.
• AWS integration configured – Complete the AWS Integration guide. You need a working vouch credential aws setup with an IAM role.
• kubectl installed (kubectl version --client).
• An EKS cluster with the API server authentication mode set to include API (either API or API_AND_CONFIG_MAP). Clusters created with the default CONFIG_MAP mode must be updated.

See EKS cluster authentication modes for details on switching to API mode, and EKS Access Entries for the Access Entries feature.

Setup

Configure kubectl to use your Vouch-backed credentials for cluster authentication:

vouch setup eks --cluster YOUR_CLUSTER_NAME

Optional flags:

• --region – AWS region (auto-detected from your AWS profile or environment if not specified).
• --profile – AWS profile to use (defaults to the auto-detected Vouch profile).
• --kubeconfig – Path to kubeconfig file (defaults to ~/.kube/config).

This command fetches the cluster endpoint and CA certificate via a native SigV4-signed EKS DescribeCluster API call, then writes or updates your kubeconfig with an exec-based user entry that calls vouch credential eks. The context is named YOUR_CLUSTER_NAME-vouch.

Verify the kubeconfig

Check that the context is set and working:

kubectl config use-context YOUR_CLUSTER_NAME-vouch
kubectl get pods

Usage

With everything configured, daily usage is straightforward:

# Start your day
vouch login

# Switch to your Vouch EKS context
kubectl config use-context YOUR_CLUSTER_NAME-vouch

# Use kubectl as normal
kubectl get pods
kubectl get namespaces
kubectl logs deployment/my-app

All authentication happens transparently. If your session expires (after 8 hours), run vouch login again.

Creating EKS Access Entries

EKS Access Entries map IAM principals (users or roles) to Kubernetes permissions. An administrator must create an Access Entry for the IAM role used by Vouch.

AWS CLI

# Create the Access Entry for the Vouch IAM role
aws eks create-access-entry \
  --cluster-name YOUR_CLUSTER_NAME \
  --principal-arn arn:aws:iam::123456789012:role/VouchDeveloper \
  --type STANDARD

# Associate an access policy (e.g., cluster admin)
aws eks associate-access-policy \
  --cluster-name YOUR_CLUSTER_NAME \
  --principal-arn arn:aws:iam::123456789012:role/VouchDeveloper \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
  --access-scope '{"type": "cluster"}'

To restrict access to specific namespaces:

aws eks associate-access-policy \
  --cluster-name YOUR_CLUSTER_NAME \
  --principal-arn arn:aws:iam::123456789012:role/VouchDeveloper \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy \
  --access-scope '{"type": "namespace", "namespaces": ["default", "staging"]}'

Terraform

resource "aws_eks_access_entry" "vouch_developer" {
  cluster_name  = aws_eks_cluster.main.name
  principal_arn = aws_iam_role.vouch_developer.arn
  type          = "STANDARD"
}

resource "aws_eks_access_policy_association" "vouch_developer_admin" {
  cluster_name  = aws_eks_cluster.main.name
  principal_arn = aws_iam_role.vouch_developer.arn
  policy_arn    = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"

  access_scope {
    type = "cluster"
  }
}

For namespace-scoped access:

resource "aws_eks_access_policy_association" "vouch_developer_edit" {
  cluster_name  = aws_eks_cluster.main.name
  principal_arn = aws_iam_role.vouch_developer.arn
  policy_arn    = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy"

  access_scope {
    type       = "namespace"
    namespaces = ["default", "staging"]
  }
}

Available Access Policies

EKS provides several built-in access policies that map to standard Kubernetes RBAC roles:

When associating a policy, choose the appropriate access scope:

• cluster – The policy applies across all namespaces.
• namespace – The policy applies only to the specified namespaces.

Cluster-scoped policies (like AmazonEKSClusterAdminPolicy) must use type: cluster. Namespace-scoped policies (like AmazonEKSEditPolicy) can use either scope type.

Custom RBAC

If the built-in access policies do not fit your needs, you can use standard Kubernetes RBAC instead. Create the Access Entry with type STANDARD and do not associate any EKS access policies. Then create Kubernetes ClusterRoleBinding or RoleBinding resources that reference the IAM role’s assumed-role ARN.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: vouch-developer-custom
subjects:
  - kind: Group
    name: "arn:aws:iam::123456789012:role/VouchDeveloper"
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: your-custom-role
  apiGroup: rbac.authorization.k8s.io

For per-user permissions using session tags from Vouch, you can create separate IAM roles per team or per access level and map each to different Kubernetes roles.

Troubleshooting

“error: You must be logged in to the server (Unauthorized)”

• Confirm you have an active Vouch session: vouch status.
• Verify AWS credentials are working: vouch credential aws.
• Check that an EKS Access Entry exists for your IAM role: aws eks list-access-entries --cluster-name YOUR_CLUSTER_NAME.
• Ensure the cluster’s authentication mode includes API. Check with: aws eks describe-cluster --name YOUR_CLUSTER_NAME --query "cluster.accessConfig.authenticationMode".

“AWS not configured” error

• Run vouch setup aws --role <role-arn> first to configure the AWS integration before setting up EKS. See the AWS Integration guide.

Credentials expire during long operations

• STS credentials obtained through Vouch last up to 1 hour. The EKS token itself is valid for 45 seconds, but kubectl re-fetches it automatically via the exec plugin on each command.
• For long-running operations such as Helm deployments or large-scale rollouts, run vouch login beforehand to ensure a fresh 8-hour session.
• If a command fails mid-operation, run vouch login and retry. The kubeconfig exec plugin will automatically pick up the new credentials.

“AccessDeniedException” when calling EKS APIs

• The IAM role assumed by Vouch needs eks:DescribeCluster permission (at minimum) to run vouch setup eks.
• For Access Entry management, the administrator’s IAM role needs eks:CreateAccessEntry, eks:AssociateAccessPolicy, and related permissions.

Cannot see resources in a specific namespace

• Check the access scope of the associated access policy. If the policy is scoped to specific namespaces, you can only access resources in those namespaces.
• Verify with: aws eks list-associated-access-policies --cluster-name YOUR_CLUSTER_NAME --principal-arn YOUR_ROLE_ARN.

kubectl works but Helm does not

• Helm may require additional permissions beyond what view or edit policies provide (e.g., creating ServiceAccount, Role, or RoleBinding resources). Consider using AmazonEKSAdminPolicy or a custom RBAC role that grants the necessary permissions.

Diagnosing configuration issues

• Run vouch doctor to detect Vouch-configured EKS contexts and check for common misconfigurations.