aws configure --profile 配置后为何命令仍使用默认凭证？

Question

**问题：** 执行 `aws configure --profile my-profile` 正确配置了自定义凭证，但运行 `aws s3 ls --profile my-profile` 仍报错“InvalidAccessKeyId”或意外使用默认 profile 的密钥？常见原因有三：一是未在命令中显式指定 `--profile my-profile`（如漏写 `--profile` 参数）；二是环境变量（如 `AWS_ACCESS_KEY_ID`、`AWS_PROFILE`）优先级高于 CLI 参数，若已设置 `AWS_PROFILE=default` 或存在冲突的环境变量，会覆盖 `--profile`；三是配置文件（`~/.aws/credentials`）中该 profile 实际未写入有效密钥，或存在拼写错误（如 `[my-proifle]` 少字母），导致 fallback 到默认 profile。验证方法：`aws configure list --profile my-profile` 查看实际加载的凭证源；`aws sts get-caller-identity --profile my-profile` 直接测试身份。根本原则：AWS CLI 加载顺序为环境变量 > `--profile` 参数 > 默认 profile，需逐层排查覆盖关系。

Answer 1

```html

一、表层现象：命令执行失败但配置看似正确

开发者执行 aws configure --profile my-profile 成功后，立即运行 aws s3 ls --profile my-profile 却收到 InvalidAccessKeyId 错误，或意外调用默认 profile 的密钥。表面看是“配置了却没生效”，实则暴露了 AWS CLI 凭证解析机制的隐式优先级规则。

二、中层机理：AWS CLI 凭证加载的三级优先级模型

AWS CLI v2（及兼容 v1）采用确定性凭证解析链，其加载顺序严格遵循以下层级（由高到低）：

1. 环境变量（如 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_PROFILE、AWS_CREDENTIAL_FILE）
2. CLI 显式参数（--profile、--access-key 等）
3. 默认 fallback 行为（[default] section in ~/.aws/credentials + ~/.aws/config）

该顺序不可覆盖、不可禁用——这是设计契约，而非 bug。

三、深层根因：三大高频失效场景与验证路径

问题层级	典型表现	诊断命令	修复动作
① 参数遗漏	误写为 aws s3 ls -profile my-profile（错用短横线）或完全省略 --profile	aws configure list --profile my-profile 显示 profile 项为 None	统一使用双横线：--profile my-profile；建议 alias 化：alias aws-my='aws --profile my-profile'
② 环境变量劫持	echo $AWS_PROFILE 输出 default；或 AWS_ACCESS_KEY_ID 非空时，--profile 完全被忽略	env | grep -i "^AWS_" + aws configure list --profile my-profile 中 access_key 来源显示 environment	临时清空：unset AWS_PROFILE AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY；长期方案：在 shell 启动文件中条件化设置
③ 配置文件结构性缺陷	~/.aws/credentials 中存在拼写错误（如 [my-proifle]）、缺少 aws_secret_access_key、或混用 ~/.aws/config 的 role_arn 但未启用 credential_source	cat ~/.aws/credentials | sed -n '/\[my-profile\]/,/^$/p' + aws sts get-caller-identity --profile my-profile --debug 2>&1 | grep -A5 "CredentialsProvider"	严格校验 INI 格式：section 名完全一致、无 BOM、无多余空格；敏感值禁止硬编码于 config；启用 credential_process 时须返回 JSON 格式凭据

四、工程级验证：构建可复现的排障流水线

以下是一套生产就绪的诊断脚本逻辑（可封装为 aws-profile-debug.sh）：

#!/bin/bash
PROFILE=${1:-my-profile}
echo "=== Step 1: Environment snapshot ==="
env | grep -i "^AWS_" | sort

echo -e "\n=== Step 2: CLI-resolved config for $PROFILE ==="
aws configure list --profile "$PROFILE"

echo -e "\n=== Step 3: Identity assertion (bypasses caching) ==="
aws sts get-caller-identity --profile "$PROFILE" --no-paginate 2>/dev/null || \
  echo "❌ Failed: likely credential source mismatch or network/IAM policy block"

echo -e "\n=== Step 4: Credential file validation ==="
grep -A5 "\[$PROFILE\]" ~/.aws/credentials 2>/dev/null || echo "⚠️  Profile section not found in credentials"

五、架构视角：为什么 AWS 设计此优先级？

该机制本质是面向云原生工作流的**安全可组合性设计**：环境变量支持 CI/CD secret 注入（如 GitHub Actions secrets）、容器 runtime 注入（EKS IRSA、ECS task role）；CLI 参数适配交互式调试；默认 profile 保障最小可用性。三者叠加形成“开发—测试—生产”凭证演进路径。忽视此设计，等于绕过 AWS IAM 最佳实践栈。

六、可视化：凭证解析决策流（Mermaid）

flowchart TD A[Start: aws s3 ls --profile my-profile] --> B{AWS_* env vars set?} B -->|Yes| C[Use env vars
--profile IGNORED] B -->|No| D{--profile specified?} D -->|Yes| E[Load [my-profile] from ~/.aws/credentials] D -->|No| F[Use [default] profile] E --> G{Section exists & valid?} G -->|Yes| H[Extract keys & call STS] G -->|No| I[Fallback to [default] or fail] H --> J[Success / InvalidAccessKeyId]

```