fix: allow providing unused ServiceAccountToken

[fletcherw]

/kind bug

What this PR does / why we need it:
When ecr-credential-provider is configured to use ServiceAccountTokens for fetching ECR credentials, it should allow ignoring those credentials if the service account doesn't have the corresponding annotations.

Update the provider to try to use a ServiceAccountToken and fall back to standard local credentials otherwise.

---

Kind of related to #1264.

Does this PR introduce a user-facing change?

Changed ecr-credential-provider to fall back to using default credentials when a ServiceAccountToken is provided but there is no corresponding role ARN provided to assume. This should not cause changes for users using the default credential provider config.

[k8s-ci-robot]

This issue is currently awaiting triage.

If cloud-provider-aws contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-ci-robot]

Hi @fletcherw. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[jicowan]

So far as I know, you can only assign 1 IAM role to a pod through IRSA. However, it's unclear whether SA token authentication requires IRSA. If the ecr-role-arn and role-arn have to be the same, then we should update this PR to only use role-arn as that is key that IRSA uses.

[fletcherw]

I'm a little new to this but this is my understanding

Each pod has exactly one service account associated with it. By default, if you annotate that service account with eks.amazonaws.com/role-arn, the pod identity agent webhook will get a service account token for that node account, assume that role and pass those credentials into the pod's containers.

Separately, before a pod is created, if there is a CredentialProvider that has matchImages matching the image URL and that configures tokenAttributes, the kubelet will also create a Service Account token and pass that to the credential provider.

I don't see why the IAM role that the credential provider assumes would have to match the role that the pod identity webhook assumes, though I'm sure that for many people they will be the same.

[kmala]

i agree that we shouldn't force to use the same arn for application and the image.

[jicowan]

Using only the ecr-role-arn did not work when I tested it. The service account needed both annotations: ecr-role-arn and role-arn. Having a separate annotation for image pulls could be useful for separating concerns: 1 role for image pulls, and another for accessing AWS APIs. Sent from Outlook<https://aka.ms/qtex0l> for iOS

…

________________________________ From: Fletcher Woodruff ***@***.***> Sent: Tuesday, October 21, 2025 12:58:44 PM To: kubernetes/cloud-provider-aws ***@***.***> Cc: Jeremy Cowan ***@***.***>; Comment ***@***.***> Subject: Re: [kubernetes/cloud-provider-aws] fix: allow providing unused ServiceAccountToken (PR #1281) @fletcherw commented on this pull request.

________________________________ On cmd/ecr-credential-provider/main.go<#1281 (comment)>: I'm a little new to this but this is my understanding Each pod has exactly one service account associated with it. By default, if you annotate that service account with eks.amazonaws.com/role-arn, the pod identity agent webhook will get a service account token for that node, assume that role and pass those credentials into the pod's containers. Separately, before a pod is created, if there is a CredentialProvider that has matchImages matching the image URL and that configures tokenAttributes, the kubelet will also create a Service Account token and pass that to the credential provider. I don't see why the IAM role that the credential provider assumes would have to match the role that the pod identity webhook assumes, though I'm sure that for many people they will be the same. — Reply to this email directly, view it on GitHub<#1281 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACCYJKZOXVIH7Y2T4M3VLBL3YZX5JAVCNFSM6AAAAACJQPIWDSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTGNRSGAZTANRXGQ>. You are receiving this because you commented.Message ID: ***@***.***>

[fletcherw]

What credential provider config were you using in that situation? If you had specified "requiredServiceAccountAnnotationKeys": ["eks.amazonaws.com/ecr-role-arn", "eks.amazonaws.com/role-arn"] it makes sense it would require both, but with optionalServiceAccountAnnotationKeys instead I think just one would be fine.

[jicowan]

I tried it with both. Required and Optional. I can re-test next week.

…

________________________________ From: Fletcher Woodruff ***@***.***> Sent: Wednesday, October 22, 2025 12:34 PM To: kubernetes/cloud-provider-aws ***@***.***> Cc: Jeremy Cowan ***@***.***>; Comment ***@***.***> Subject: Re: [kubernetes/cloud-provider-aws] fix: allow providing unused ServiceAccountToken (PR #1281) [https://avatars.githubusercontent.com/u/4389439?s=20&v=4]fletcherw left a comment (kubernetes/cloud-provider-aws#1281)<#1281 (comment)> What credential provider config were you using in that situation? If you had specified "requiredServiceAccountAnnotationKeys": ["eks.amazonaws.com/ecr-role-arn", "eks.amazonaws.com/role-arn"] it makes sense it would require both, but with optionalServiceAccountAnnotationKeys instead I think just one would be fine. — Reply to this email directly, view it on GitHub<#1281 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACCYJKZGJWJPDTHRQICJEXT3Y653HAVCNFSM6AAAAACJQPIWDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMZTGQ3DANZZHE>. You are receiving this because you commented.Message ID: ***@***.***>

[kmala]

/ok-to-test

[fletcherw]

/release-note-edit

Changed ecr-credential-provider to fall back to using default credentials when a ServiceAccountToken is provided but there is no corresponding role ARN provided to assume. This should not cause changes for users using the default credential provider config from EKS AMIs.

[k8s-ci-robot]

@fletcherw: You must be an org member to edit the release note.

In response to this:

/release-note-edit

Changed ecr-credential-provider to fall back to using default credentials when a ServiceAccountToken is provided but there is no corresponding role ARN provided to assume. This should not cause changes for users using the default credential provider config from EKS AMIs.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[kmala]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kmala

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [kmala]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kmala]

/release-note-none