Add --api-version flag to aws eks get-token to support newer versions

[stevehipwell]

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

• 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

[YvanGuidoin]

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

[stevehipwell]

@YvanGuidoin I added the aws eks update-kubeconfig to the description too.

[tim-finnigan]

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 #6308.

I think the first priority is reviewing the PR linked to that issue (#6476). Then the team can review this feature request for consideration.

[stevehipwell]

@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.

[micahhausler]

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.

[kyleknap]

Since merging #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.

[mhemken-vts]

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.

[stevehipwell]

@mhemken-vts which provider and AWS CLI versions are you using? It should be working correctly now.

[ulidtko]

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.