aws-cli
aws-cli copied to clipboard
Add `--api-version` flag to `aws eks get-token` to support newer versions
Describe the feature
I'd like to be able to request a specific client.authentication.k8s.io
API version to be returned when calling aws eks get-token
via a --api-version
flag.
For example aws eks get-token --cluster-name my-cluster --api-version v1beta1
.
We would need the same flag for the aws eks update-kubeconfig
command too.
Use Case
When using aws eks get-token
as a client-go credential plugin the API version being used needs to be specified in the calling code. This means changing the default in the command will break all usages until both the binary and calling code have been updated. By adding the --api-version
flag the calling code will always be valid as long as the specified API version is supported by the cluster.
Proposed Solution
Add a --api-version
flag to the aws eks get-token
. Either only support API versions which are available in all EKS versions or error if the API version isn't available on the cluster.
Other Information
With the release of Kubernetes v1.24.0 client.authentication.k8s.io/v1alpha1
has been removed.
Acknowledgements
- [X] I may be able to implement this feature request
- [ ] This feature might incur a breaking change
CLI version used
n/a
Environment details (OS name and version, etc.)
All
Hello,
Blocked for the same reason on aws eks update-kubeconfig
trying to update our dev estate, generated config uses client.authentication.k8s.io/v1alpha1
@YvanGuidoin I added the aws eks update-kubeconfig
to the description too.
Thanks @stevehipwell for creating an issue to track this feature request. I saw that a maintainer had mentioned the possibility of this feature here in https://github.com/aws/aws-cli/issues/6308.
I think the first priority is reviewing the PR linked to that issue (https://github.com/aws/aws-cli/pull/6476). Then the team can review this feature request for consideration.
@tim-finnigan the API version needs to be specified as the CLI call needs to be deterministic, I think the --api-version
flag is the only way to do this and support all the places where this is used as env variables aren't granular enough. For example a kubeconfig with multiple clusters supporting different API versions all using exec plugins.
It'd also be a much simpler implementation; #6476 has been open about 7 months.
I think adding an API version flag is redundant and will only introduce confusion and break users who set an incorrect value.
As noted in #6940, prior to Kubernetes 1.20, the API version environment variable was only provided to executables (such as the AWS CLI) if the kubeconfig specified client.authentication.k8s.io/v1alpha1
. After EKS ends support for Kubernetes 1.19 in about a month, all versions of client-go (used by kubectl, kubelet, helm, etc) supported by EKS will provide KUBERNETES_EXEC_INFO
with a correct value.
The only case where the CLI will have to make an inference is when KUBERNETES_EXEC_INFO
is blank. Right now the CLI will default to client.authentication.k8s.io/v1beta1
when unset (compatible with 1.11 thru 1.29), but in the future will likely include a message to stderr that the env var was blank, and instruct users to provide the value.
If a --client-api-version
flag were provided with the correct value, it would be redundant to KUBERNETES_EXEC_INFO
. If it were provided with a different version than the kubeconfig and the AWS CLI returned that API version, the calling process (kubectl, kubelet, helm, etc) would error out.
Since merging https://github.com/aws/aws-cli/pull/6940, I would agree a --api-version
or --client-api-version
parameter for the eks get-token
command is not something we would look to pursue adding, unless there are strong examples of where KUBERNETES_EXEC_INFO
will not be set going forward in the latest tooling and a flag is needed as a workaround. Feel free to comment in this issue with examples.
That being said, I do think it is a reasonable ask to provide the --api-version
or --client-api-version
for the eks update-kubeconfig
. Right now the command defaults to setting the API version in the ~/.kube/config
to client.authentication.k8s.io/v1beta1
but there is not a programmatic way to set the API version in the ~/.kube/config
to client.authentication.k8s.io/v1
if you wanted to upgrade usage.
When using Hashicorp's Kubernetes provider using the exec configuration the API version remains v1alpha1
even when we explicitly set it to v1beta1
. The flag I'm looking for is --force-v1beta1-I-dont-give-a-damn
.
@mhemken-vts which provider and AWS CLI versions are you using? It should be working correctly now.
Perhaps another usecase is awscli v1. I could only get it to work with kubectl downgrade below 1.24.0.
Due to #4947, in some environments v2 is not installable.