1.13.2: aws-iam-authenticator now finding /root/.aws/config
#2989
Labels
area/core
Issues core to the OS (variant independent)
status/icebox
Things we think would be nice but are not prioritized
type/bug
Something isn't working
Image I'm using:
Upgrading
Bottlerocket OS 1.13.1 (aws-k8s-1.22)
toBottlerocket OS 1.13.2 (aws-k8s-1.22)
What I expected to happen:
A successful upgrade.
What actually happened:
Nodes failed to successfully authenticate with the cluster.
How to reproduce the problem:
I apologize that this might be long, and that the config/goals might feel a little odd.
Start nodes with the following configuration:
Where the
settings.aws.config
is something like:The role attached to the instance, and the additional role referenced above have all the correct permissions to allow the assume role to take place. Additionally, the instance role and the extra role have the same set of permissions attached to them (the required AmazonEKSWorkerNodePolicy and AmazonEC2ContainerRegistryReadOnly).
When the v1.13.1 instance starts up, the older v0.6.2 version of the
aws-iam-authenticator
would use the instance's role to generate the token needed to authenticate with the control plane. With the 1.13.2 version, which contains the v0.6.8 of theaws-iam-authenticator
, it will discover the/root/.aws/config
file and will make use of the default provider to create the token for authenticating the node with the control plane. This change in behavior was due to aws/aws-sdk-go#4519 being included in theaws-sdk-go
library upgrades. That PR adds a fallback to read the home directory information from/etc/passwd
if theHOME
environment variable is not set.The assumed role is not able to authenticate with the control plane, even if the aws-auth ConfigMap is updated to support the different role, because the SessionName used by the assumed role does not contain the instance ID.
To get the instance to connect correctly, the AWS config file can be changed to use a profile with a name other than default. The use of
default
was suggested in #2885 (comment). With #2904 and #2924 we were able to go back to using a name other thandefault
which works.I can see a few resolutions out of this issue, and mostly filing it to get feedback and consideration.
EC2PrivateDNSName
substitution works.It would be nice if we could get the
aws-iam-authenticator
to use the separated role for auth, but since that is just identity auth it isn't as immediately interesting as being able to remove all the policies attached to the instance role.References:
aws.profile
not respected inecr-credential-provider
template. #2885 - prior attempts at settingsettings.aws.config
.The text was updated successfully, but these errors were encountered: