Alpine Linux容器中aws-cli认证报UnrecognizedClientException问题排查

Let's break down the possible issues and fixes for this problem, since you confirmed the command works locally but fails in your Alpine container:

1. Verify Environment Variables Are Persisted Correctly #

The most common culprit here is how you're setting your AWS credentials in the Docker context. If you used RUN export AWS_ACCESS_KEY_ID=... in your Dockerfile, those variables won't stick around in the running container—each RUN command runs in a separate shell session that doesn't persist environment variables to future layers or runtime.

• Fix: Use Docker's ENV directive in your Dockerfile to set the credentials permanently in the image:

  ENV AWS_ACCESS_KEY_ID=XXXXXXXXXXXXXXXXXXXX
  ENV AWS_SECRET_ACCESS_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  ENV AWS_DEFAULT_REGION=eu-central-1
  

  Or pass them at runtime with the -e flag (safer than hardcoding in the image):

  docker run -e AWS_ACCESS_KEY_ID=XXX -e AWS_SECRET_ACCESS_KEY=XXX -e AWS_DEFAULT_REGION=eu-central-1 your-alpine-image
  

• Verify: Exec into the container and run echo $AWS_ACCESS_KEY_ID and echo $AWS_SECRET_ACCESS_KEY to confirm the values match what you use locally (no typos or truncated strings).

2. Switch to Alpine's Native AWS CLI Package #

Installing AWS CLI via pip on Alpine (which uses musl libc instead of glibc) can lead to subtle compatibility issues. The Alpine repo has a pre-built, musl-compatible version of AWS CLI that's more reliable.

• Fix: Replace your pip installation steps with:

  apk add --update aws-cli
  

• Bonus: If you need AWS CLI v2 (since v1 is deprecated), you can download the official binary for Alpine:

  apk add --update curl unzip
  curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
  unzip awscliv2.zip
  ./aws/install
  

3. Double-Check IAM Permissions for the Credentials #

Even though the command works locally, make sure the exact credentials you're using in the container have the ecr:GetAuthorizationToken permission. It's possible your local environment is using a different IAM profile (from ~/.aws/credentials) that has broader permissions.

• Verify: Run this command locally (with the same credentials you're using in Docker) to test the permission:

  aws iam simulate-principal-policy \
    --policy-source-arn arn:aws:iam::YOUR_ACCOUNT_ID:user/YOUR_USERNAME \
    --action-names ecr:GetAuthorizationToken
  

  Look for Allowed: true in the output.

4. Ensure Region Consistency #

While you're specifying --region eu-central-1 in the command, some AWS CLI operations still rely on the AWS_DEFAULT_REGION environment variable being set. Missing this can cause unexpected credential resolution issues.

• Fix: Add export AWS_DEFAULT_REGION=eu-central-1 (or use ENV in Dockerfile) alongside your other credential variables.

A Quick Security Note #

Hardcoding AWS credentials in your Dockerfile is a bad practice—anyone with access to the image can extract them. For production, consider using Docker Secrets, AWS IAM Roles for Service Accounts (if running on EKS/ECS), or passing credentials at runtime securely.

内容的提问来源于stack exchange，提问作者cute_marmalade