## The idea is:
Add support for `AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE` in n8n’s AWS credential handling to enable native authentication with Amazon EKS Pod Identity.
Currently, n8n’s “Use System Credentials” option works with ECS Task Roles and EC2 Instance Profiles, but it doesn’t support EKS Pod Identity because it only checks for the `AWS_CONTAINER_AUTHORIZATION_TOKEN` environment variable (direct token). EKS Pod Identity uses `AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE` instead, which points to a file containing the token.
The enhancement would:
- Check for `AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE` first (used by EKS Pod Identity)
- Read the token from the file if it exists
- Fall back to `AWS_CONTAINER_AUTHORIZATION_TOKEN` if the file isn’t available (maintaining backward compatibility with ECS)
- Follow the same credential provider chain as the official AWS SDKs
## My use case:
I’m deploying n8n on Amazon EKS (Elastic Kubernetes Service) and want to use EKS Pod Identity to provide AWS credentials to n8n. This is AWS’s recommended authentication method for Kubernetes workloads on EKS.
**Current situation:**
- When n8n is deployed on EKS with Pod Identity configured, EKS automatically injects the `AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE` environment variable pointing to a mounted token file (e.g., `/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token`)
- n8n only looks for `AWS_CONTAINER_AUTHORIZATION_TOKEN` (direct token), so it fails to detect the EKS Pod Identity credentials
- All AWS nodes (S3, Lambda, DynamoDB, etc.) fail with authentication errors
**Current workarounds (all less ideal):**
- Use IAM Roles for Service Accounts (IRSA) - more complex setup requiring OIDC provider configuration
- Hardcode credentials in n8n - security anti-pattern, not recommended
- Use EC2 instance profiles - broader permissions, less secure, violates principle of least privilege
## I think it would be beneficial to add this because:
1. **Simplified Deployment**: EKS Pod Identity is simpler to set up than IRSA (no OIDC provider needed) and is AWS’s recommended approach for new EKS deployments.
2. **Better Security**:
- Eliminates the need for hardcoded credentials
- Supports fine-grained IAM permissions per pod
- Tokens are automatically rotated by AWS
- Follows AWS security best practices
3. **AWS Standard Compliance**: The official AWS SDKs already support both `AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE` (file-based) and `AWS_CONTAINER_AUTHORIZATION_TOKEN` (direct). n8n should follow the same standard.
4. **Wider Compatibility**: This makes n8n work seamlessly with:
- EKS Pod Identity (file-based) ← Currently broken
- ECS Task Roles (direct token) ← Already works
- Any other AWS container credential provider
5. **No Breaking Changes**: This is purely additive - it checks for the file-based token first, then falls back to the existing direct token approach. All existing implementations continue to work unchanged.
## Any resources to support this?
- **EKS Pod Identity Documentation**: Learn how EKS Pod Identity grants pods access to AWS services - Amazon EKS
- **AWS SDK Container Credentials Provider**: Container credential provider - AWS SDKs and Tools
- This documents that AWS SDKs check both `AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE` (file path - takes precedence) and `AWS_CONTAINER_AUTHORIZATION_TOKEN` (direct token)
- **Related GitHub Issue**: AWS credentials missing support for AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE · Issue #21581 · n8n-io/n8n · GitHub
- **Related Issue on Default Credential Chain**: AWS Credential(s) does not respect default credential chain (IRSA / EC2 instance profile support) · Issue #21568 · n8n-io/n8n · GitHub
## Are you willing to work on this?
**Yes!** I’ve already implemented the feature with comprehensive automated tests and created a pull request. The implementation:
- Adds file-based token support to the `getPodIdentityCredentials()` function
- Includes 7 test cases covering all scenarios (file reading, fallback behavior, precedence, backward compatibility)
- Maintains 100% backward compatibility
- Follows AWS SDK standard behavior
- Is ready for review and merge
The code changes are minimal (about 15 lines) and the implementation is straightforward since it just needs to read a file before falling back to the existing environment variable check.