ECS环境下AWS SDK for Node.js无法获取凭证问题排查求助

Let's break down your issue step by step. You've confirmed the ECS task role has S3 permissions, the container can reach the metadata service via curl, but the AWS SDK isn't picking up credentials correctly—resulting in AWS.config.credentials being null and a 403 error. Here's what to check and fix:

Possible Root Causes & Fixes #

1. AWS SDK Version Compatibility #

Older versions of the AWS SDK for JavaScript (especially v2) might have inconsistent support for ECS container credentials. First, verify your SDK version:

npm list aws-sdk

If you're on a version older than 2.1000.0, consider upgrading to a more recent v2 release or migrating to v3 (which has more robust credential handling by default). For v2, newer releases ensure the SDK can properly resolve the ECS credential provider.

2. Credential Provider Chain Not Triggered Correctly #

Even though ECSCredentials is in the default provider chain, the SDK might not fall back to it if:

• You've accidentally set AWS.config.credentials to null somewhere in your code before the S3 call.
• The SDK tries to resolve credentials synchronously, but ECS credentials load asynchronously.

Try explicitly initializing the credential provider to force the SDK to use the ECS metadata service:

const AWS = require('aws-sdk');
const { ECSCredentials } = require('aws-sdk/lib/credentials/ecs_credentials');

// Explicitly use ECS credentials provider with timeout/retry settings
AWS.config.credentials = new ECSCredentials({
  httpOptions: { timeout: 5000 },
  retryDelayOptions: { base: 200 }
});

// Wait for credentials to load before making the S3 call
AWS.config.credentials.get((err) => {
  if (err) {
    console.error('Failed to load ECS credentials:', err);
    return;
  }
  uploadAllToS3();
});

3. IAM Role Permission Scope #

Double-check that your ECS task role has exact permissions for the S3 bucket operation. Even if you think it's correct, verify the policy includes the precise resource pattern matching your code:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/test/*"
    }
  ]
}

The test/* wildcard ensures it matches your code's test/${new Date()}.txt key pattern.

Additional Logs to Debug Further #

Add these logs to get deeper visibility into the credential resolution process:

• Enable SDK debug logs to track provider chain attempts:

  AWS.config.logger = console; // Logs all SDK internal credential resolution steps
  

• Log partial credential details (redact sensitive info for security):

  AWS.config.credentials.get((err, creds) => {
    if (creds) {
      console.log('Loaded credentials:', {
        accessKeyId: creds.accessKeyId?.slice(0, 4) + '...', // Show only first 4 chars
        expiration: creds.expiration,
        providerType: creds.provider?.constructor.name
      });
    }
  });
  

• Check for conflicting environment variables that might override credential logic:

  const relevantEnvVars = ['AWS_ACCESS_KEY_ID', 'AWS_SECRET_ACCESS_KEY', 'AWS_SESSION_TOKEN', 'AWS_CONTAINER_CREDENTIALS_RELATIVE_URI'];
  console.log('Relevant env vars:', relevantEnvVars.reduce((acc, key) => ({ ...acc, [key]: process.env[key] }), {}));
  

Why Your Local Test Works #

When you manually assume the role locally, you're setting AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in the environment—so the SDK picks these up via EnvironmentCredentials, skipping the ECS metadata provider entirely. The ECS environment relies on the metadata service, which requires the SDK to properly resolve the relative URI from the environment variable.

内容的提问来源于stack exchange，提问作者Cui Pengfei 崔鹏飞