Python调用boto3时如何正确配置AWS凭证？

Question

**常见问题：** 在Python中使用boto3调用AWS服务时，常因凭证配置错误导致 `NoCredentialsError` 或 `ClientError: InvalidToken`。典型误区包括：误将密钥硬编码在代码中（违反安全最佳实践）；混淆 `~/.aws/credentials` 与 `~/.aws/config` 文件的格式（如将 `region` 写在 `credentials` 文件却未启用 `credential_process`）；多Profile场景下未正确指定 `profile_name`；或在容器/EC2环境中忽略IAM角色优先级，错误覆盖环境变量（如 `AWS_ACCESS_KEY_ID`）导致权限降级。此外，使用临时凭证（如STS AssumeRole）时未定期刷新，易引发 `ExpiredTokenException`。如何按安全、可维护、环境自适应的原则，分开发、测试、生产阶段选择最合适的凭证加载方式（如Shared Credentials File、Environment Variables、IAM Roles、SSO或Custom Credential Providers），并验证其生效顺序（遵循AWS CLI定义的[credential provider chain](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html)），是工程落地的关键挑战。

Answer 1

```html

一、凭证失效的表象：从错误日志反推根源

当出现 NoCredentialsError，说明boto3未在任何环节获取到有效凭证；而 ClientError: InvalidToken 或 ExpiredTokenException 则表明已加载凭证，但其签名无效或已过期。二者本质不同：前者是「零凭证」，后者是「坏凭证」。典型日志片段如下：

botocore.exceptions.NoCredentialsError: Unable to locate credentials
botocore.exceptions.ClientError: An error occurred (InvalidToken) when calling the ListBuckets operation
botocore.exceptions.ClientError: An error occurred (ExpiredToken) when calling the AssumeRole operation

二、AWS凭证加载链（Credential Provider Chain）深度解析

boto3严格遵循官方定义的11级加载顺序，优先级由高到低如下（关键6级精简版）：

1. Environment variables（AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN）
2. Shared credentials file（~/.aws/credentials，支持多profile）
3. Shared config file（~/.aws/config，仅当启用 credential_process 或 SSO 时参与凭证生成）
4. Container credentials（Docker/ECS：HTTP endpoint http://169.254.170.2）
5. EC2 instance metadata service（IMDSv2 优先，需 token + GET）
6. Custom credential providers（通过 Session.set_credentials() 或自定义 Credentials 类注入）

⚠️ 注意：~/.aws/config 中的 region 不提供凭证，仅影响默认区域；若混写 aws_access_key_id 到 config 文件，boto3将静默忽略——这是高频配置陷阱。

三、分环境凭证策略设计矩阵

环境	推荐方式	安全依据	可维护性要点
本地开发	SSO Login + aws sso login --profile dev-sso	零长期密钥，自动轮转，MFA强制	配合 ~/.aws/config 的 sso_start_url/sso_region 声明
CI/CD 测试	Environment Variables（由Secrets Manager注入）	生命周期绑定Job，无磁盘残留	使用 export AWS_PROFILE=test-env 显式隔离，禁用 AWS_ACCESS_KEY_ID 直接赋值
容器化生产（EKS/ECS）	IAM Roles for Service Accounts（IRSA）或 Task Role	JWT令牌自动签发，最小权限原则可精确到Pod级别	避免在Dockerfile中 ENV AWS_*；使用 aws-iam-authenticator 验证OIDC信任关系

四、硬编码密钥的“五步替代法”实践路径

1. 立即删除代码中所有 aws_access_key_id=... 字符串
2. 创建专用IAM用户（如 dev-boto3-bootstrap），仅授予 sts:AssumeRole 权限
3. 在 ~/.aws/credentials 中配置该用户为 [bootstrap] profile
4. 编写安全的AssumeRole工具函数（含自动刷新逻辑）：

def get_assumed_session(role_arn: str, session_name: str = "boto3-session") -> boto3.Session:
    sts = boto3.client("sts", profile_name="bootstrap")
    resp = sts.assume_role(RoleArn=role_arn, RoleSessionName=session_name)
    return boto3.Session(
        aws_access_key_id=resp["Credentials"]["AccessKeyId"],
        aws_secret_access_key=resp["Credentials"]["SecretAccessKey"],
        aws_session_token=resp["Credentials"]["SessionToken"],
        region_name="us-east-1"
    )

五、临时凭证生命周期治理：自动刷新状态机

针对 ExpiredTokenException，必须实现凭证有效期感知与预刷新。以下为基于 RefreshableCredentials 的轻量方案核心逻辑：

graph LR
A[初始化Session] --> B{Credentials expired?}
B -->|Yes| C[调用STS AssumeRole]
C --> D[更新Credentials对象]
D --> E[返回新凭证]
B -->|No| F[直接返回当前凭证]

六、调试与验证：四层诊断法

1. 环境层：运行 aws configure list 查看当前生效profile及来源标记（env, shared-credentials-file, iam-role）
2. SDK层：启用boto3 debug日志：boto3.set_stream_logger('botocore.credentials', logging.DEBUG)
3. 网络层：抓包验证是否命中IMDSv2（curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"）
4. 权限层：使用 aws sts get-caller-identity 输出ARN，并比对IAM Policy Simulator结果

```