Support EKS Pod Identity in amazon-ecr-login action (caused by #624)

[younsl]

Is your feature request related to a problem? Please describe.

Currently, GitHub Actions aws-actions/amazon-ecr-login step doesn't support EKS Pod Identity authentication method, requiring separate AWS credentials management.

This forces us to maintain IRSA configuration for our self-hosted runners, which adds complexity and prevents us from fully migrating to the new EKS Pod Identity feature. Due to this limitation, unable to migrate our Actions Runner Pod's IAM permission configuration from IRSA to EKS Pod Identity.

Describe the solution you'd like

Describe alternatives you've considered

1. Continue using IRSA (current alternative solution)
   • Works but requires additional setup and maintenance
   • Prevents full migration to Pod Identity
   • More complex IAM configuration
2. Use AWS credentials directly in GitHub Actions secrets
   • Less secure approach
   • Requires credential rotation
   • Not following AWS best practices
3. Create a custom action for ECR login
   • Would require maintaining our own action
   • Adds unnecessary development overhead

Additional context

• We are currently running self-hosted runners in EKS with Pod Identity enabled for other AWS service interactions
• Our infrastructure is defined in Terraform and already supports Pod Identity
• AWS EKS Pod Identity documentation: https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html
• This feature will resolve Action does not support EKS pod identities #624

[ddukbg]

@younsl

I'm not an expert in GitHub Actions or AWS SDK internals, but I ran into an issue when using EKS Pod Identity with this action. Specifically, the login step fails with an error stating that "169.254.170.23 is not a valid container metadata service hostname." This happens because the action picks up container credential environment variables that aren't valid in our EKS Pod Identity setup.

Temporary Workaround:

As a quick fix, I applied a temporary workaround by overriding the problematic environment variables in our workflow. This forces the action to bypass the invalid default values so that our self-hosted runners can properly use the Pod Identity credentials. Here's the workaround:

- name: Login to Amazon ECR
  id: login-ecr
  uses: actions/amazon-ecr-login@v1
  env:
    AWS_CONTAINER_CREDENTIALS_FULL_URI: ''
    AWS_CONTAINER_CREDENTIALS_RELATIVE_URI: ''

Why This Works:

• Problem: Without overriding, the action reads AWS_CONTAINER_CREDENTIALS_FULL_URI (which points to 169.254.170.23) and fails.
• Solution: By setting these environment variables to empty strings, the action avoids using the invalid endpoint and falls back to using the correct Pod Identity credentials (via, for example, AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE).

I'm not very experienced with development, but I'll be opening a PR with this temporary workaround. Hopefully, this helps others until native EKS Pod Identity support is implemented in the action.