-
Notifications
You must be signed in to change notification settings - Fork 4.4k
Description
Describe the feature
Provide a separate argument like --exec-profile
that allows you to specify what profile should be used when invoking the exec
command (i.e. what ends up as AWS_PROFILE in env
).
Use Case
Currently it is assumed that the same profile that is used when calling aws eks update-kubeconfig
is what should be used when getting the token. This is problematic for us when it comes to environments that require privilege escalation in order to get access to the cluster.
To give a simple example, consider the following two profiles:
read-only
- has read access to AWSadmin
- has no permissions unless going through a privilege escalation process
We now want to create two sets of configuration contexts for a cluster, one that grants read-only access and one that requires privilege escalation before getting admin access.
read-only
can describe clusters and can thus be used withaws eks update-kubeconfig --profile read-only ...
. No problem.- The
admin
role, however, has no permissions unless you go through a privilege escalation process. Thereforeaws eks update-kubeconfig --profile admin ...
will fail because the role will not have permission to callDescribeCluster
.
Proposed Solution
If we allowed specifying what profile should be used in the exec command separately, we could do: aws eks update-kubeconfig --profile read-only --exec-profile admin ...
, the read-only profile would call DescribeCluster in order to create the config file, which would have the admin
profile set as AWS_PROFILE
in the kube config.
Other Information
Currently we are having to work around this by initializing our configuration always using the read-only
profile and then parsing the resulting config file to replace the profile in the env
section with the admin
profile where needed.
This feature is somewhat similar to the --assume-role-arn
option, but that unfortunately just uses the current session profile to assume the role when describing the cluster. In this case that would mean that the role referenced by the admin
profile would need to be able to assume the role referenced by the read-only
profile, which won't work.
Acknowledgements
- I may be able to implement this feature request
- This feature might incur a breaking change
CLI version used
aws-cli/2.30.7
Environment details (OS name and version, etc.)
Python/3.13.7 Darwin/24.6.0 source/arm64