Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Tell us about your request
The kubectl-connect helper that ships in a VPC CloudShell environment opened by the EKS console's Connect button should accept a --role-arn argument and pass it through to aws eks update-kubeconfig.
Three concrete changes, in priority order:
- Accept
--role-arn <arn> and forward it to aws eks update-kubeconfig.
- Do not silently ignore unrecognised arguments — fail, or warn.
- Do not short-circuit on an existing kubeconfig when arguments are supplied that would change the configuration.
Which service(s) is this request for?
EKS (and CloudShell, insofar as the helper ships with the VPC environment the Connect button creates)
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Access entries take exactly one literal IAM principal ARN and support no wildcard. For IAM Identity Center users, the role a permission set provisions into an account carries a 16-hex suffix that is regenerated on every reprovision, so a pinned AWSReservedSSO_<name>_<hash> ARN goes stale out of band. EKS does not validate that the principal exists, so the access entry silently grants nobody anything. This is #474, open since 2019.
The workaround AWS's own documentation points to — and which #2336 describes as what customers actually do — is to stop naming the SSO role in the access entry. Instead you create a durable IAM role, name that in the access entry, and put the rotating hash in the durable role's trust policy as an ArnLike condition on aws:PrincipalArn, which is the one place ARN patterns are supported. Users then reach the cluster with:
aws eks update-kubeconfig --name <cluster> --region <region> --role-arn <durable-role-arn>
This works correctly from a normal shell. It cannot be expressed through the Connect button, which is the primary access path for private-endpoint clusters, because kubectl-connect always configures kubectl as the ambient console session principal — the very principal that, under this pattern, deliberately has no access entry.
The result is that the Connect button's headline behaviour ("CloudShell opens with kubectl already pointed at the cluster") produces a kubectl that cannot authenticate, and the error names no cause:
$ source kubectl-connect <cluster>
Configuring kubectl for EKS cluster: <cluster>
Added new context <cluster> to /home/cloudshell-user/.kube/config-<cluster>
Successfully configured kubectl for cluster: <cluster>
Environment configured. KUBECONFIG is set to: /home/cloudshell-user/.kube/config-<cluster>
⚠️ Configuration complete, but unable to connect to cluster <cluster>
Current context: <cluster>
E0902 12:57:00.525434 224 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: the server has asked for the client to provide credentials"
...
error: You must be logged in to the server (the server has asked for the client to provide credentials)
This may be due to:
• Network connectivity issues
• Invalid cluster credentials or permissions
• Cluster does not exist or is not accessible
• AWS credentials are incorrect or expired
None of the four suggested causes is the actual one. The credentials are valid, the network is fine (a 401 proves the API server was reached), and the cluster exists. The principal simply has no access entry.
Supplying the flag explicitly does not help — it is accepted without complaint and has no effect, and the helper additionally declines to reconfigure:
$ source kubectl-connect <cluster> --role-arn arn:aws:iam::111122223333:role/eks-access/<cluster>-admin
Cluster <cluster> already configured, switching to existing configuration
Successfully configured kubectl for cluster: <cluster>
...
error: You must be logged in to the server (the server has asked for the client to provide credentials)
So an operator who already knows the correct answer still cannot apply it through the supported path. Both behaviours compound: the flag is dropped, and the stale context is reused.
Are you currently working around this issue?
Yes, by documenting that users should disregard the helper the Connect button just ran for them, and instead run:
aws eks update-kubeconfig --name <cluster> --region <region> \
--role-arn arn:aws:iam::111122223333:role/eks-access/<cluster>-admin --alias <cluster>-role
kubectl config use-context <cluster>-role
This works, but it means the Connect button actively misleads: it reports success, sets KUBECONFIG, changes the prompt to [k8s: <cluster>], and leaves the user with a kubectl that 401s. Every operator has to learn this once by hitting an error message that points at four wrong causes.
Additional context
Community Note
Tell us about your request
The
kubectl-connecthelper that ships in a VPC CloudShell environment opened by the EKS console's Connect button should accept a--role-arnargument and pass it through toaws eks update-kubeconfig.Three concrete changes, in priority order:
--role-arn <arn>and forward it toaws eks update-kubeconfig.Which service(s) is this request for?
EKS (and CloudShell, insofar as the helper ships with the VPC environment the Connect button creates)
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Access entries take exactly one literal IAM principal ARN and support no wildcard. For IAM Identity Center users, the role a permission set provisions into an account carries a 16-hex suffix that is regenerated on every reprovision, so a pinned
AWSReservedSSO_<name>_<hash>ARN goes stale out of band. EKS does not validate that the principal exists, so the access entry silently grants nobody anything. This is #474, open since 2019.The workaround AWS's own documentation points to — and which #2336 describes as what customers actually do — is to stop naming the SSO role in the access entry. Instead you create a durable IAM role, name that in the access entry, and put the rotating hash in the durable role's trust policy as an
ArnLikecondition onaws:PrincipalArn, which is the one place ARN patterns are supported. Users then reach the cluster with:This works correctly from a normal shell. It cannot be expressed through the Connect button, which is the primary access path for private-endpoint clusters, because
kubectl-connectalways configures kubectl as the ambient console session principal — the very principal that, under this pattern, deliberately has no access entry.The result is that the Connect button's headline behaviour ("CloudShell opens with
kubectlalready pointed at the cluster") produces a kubectl that cannot authenticate, and the error names no cause:None of the four suggested causes is the actual one. The credentials are valid, the network is fine (a 401 proves the API server was reached), and the cluster exists. The principal simply has no access entry.
Supplying the flag explicitly does not help — it is accepted without complaint and has no effect, and the helper additionally declines to reconfigure:
So an operator who already knows the correct answer still cannot apply it through the supported path. Both behaviours compound: the flag is dropped, and the stale context is reused.
Are you currently working around this issue?
Yes, by documenting that users should disregard the helper the Connect button just ran for them, and instead run:
This works, but it means the Connect button actively misleads: it reports success, sets
KUBECONFIG, changes the prompt to[k8s: <cluster>], and leaves the user with a kubectl that 401s. Every operator has to learn this once by hitting an error message that points at four wrong causes.Additional context
--role-arnpass-through remains useful for any cluster whose access is granted through an assumable role — cross-account access, break-glass roles, and CI principals all have the same shape.