aws-iam-authenticator, Run To Its First AWS Call

aws-iam-authenticator

Kubernetes SIGs aws-iam-authenticator on EL 10 from the vendor's release, checked against the published SHA-256, pinned to a version, installed as root's binary in /usr/local/bin. Original role for EL 10, live-tested with podman on Rocky Linux 10.

No package worth the name. EL 10 carries no aws-iam-authenticator, and a third-party repository is one more key to trust. This role takes the release from github.com/kubernetes-sigs/aws-iam-authenticator, has Ansible's get_url refuse the asset unless its SHA-256 is the published one, and the live test checks the asset on disk against the same published value again.

Pinned. aws_iam_version is what gets installed, kept in a directory of its own so the checksum file and the asset it names stay together. A newer release is a variable change and a run; the same version is changed=0.

Proven to run. The live test runs aws-iam-authenticator token -i probe --region eu-north-1 and expects "get credentials" - the binary ran all the way to the point where it needed something this host does not have.

Run to its first AWS call. aws-iam-authenticator token -i <cluster> presigns an STS GetCallerIdentity request; with no credentials (and the instance metadata service disabled, so it does not wait on it) it stops at "get credentials", which the live test expects. This is the exec plugin aws eks update-kubeconfig writes for older kubeconfigs and the one EKS clusters without the AWS CLI on the client still use; credentials come from the usual AWS chain. The checksum file is named authenticator_<v>_checksums.txt, not after the binary.

License

Commercial - IaC Bazaar EULA. (c) IaC Bazaar.