为何ECS任务无法连接S3存储桶？MLflow凭证问题排查

核心原因：MLflow处理S3 artifacts时，是由你的应用代码直接调用AWS S3 API，而非通过MLflow服务器中转。所以需要ECS任务中的代码能获取到有效的AWS凭证，而非依赖MLflow服务器的权限。以下是具体排查和解决步骤：

• 区分ECS执行角色与任务角色
  很多人会混淆executionRoleArn和taskRoleArn：

  • executionRoleArn是给ECS服务本身用的（比如拉取镜像、写入CloudWatch日志），不会让任务内的代码获取权限；
  • 你的MLflow代码需要的是任务角色（taskRoleArn），要确保任务定义中正确配置了这个参数，且该角色拥有S3操作的全权限。
    验证方式：在ECS任务中执行aws s3 ls <你的S3桶名>，如果无法访问，说明角色配置错误。

• 检查任务角色的信任关系
  任务角色的信任策略必须允许ECS任务服务扮演它，正确的信任策略示例：

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "ecs-tasks.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
      }
    ]
  }
  

  若信任关系不正确，ECS任务无法获取AWS临时凭证。

• 清理代码中的硬编码凭证
  检查你的MLflow代码是否手动设置了AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY这类环境变量，或是加载了本地~/.aws/credentials文件。这些配置会覆盖ECS角色的临时凭证，导致代码无法自动获取任务角色权限。
  可以在代码中添加调试代码验证凭证获取情况：

  import boto3
  session = boto3.Session()
  credentials = session.get_credentials()
  print(f"当前凭证: {credentials}")
  

  若输出为None，说明任务未成功获取临时凭证。

• 验证VPC网络连通性
  若ECS任务部署在私有子网：

  • 需确保任务能访问AWS STS服务（用于获取临时凭证），可以通过配置NAT网关让任务访问公网STS端点，或是在VPC中创建STS的VPC端点（com.amazonaws.<区域>.sts）；
  • 无法访问STS时，任务无法获取临时凭证，会直接触发NoCredentialsError。

• 检查S3桶的权限策略
  即便任务角色拥有S3全权限，若S3桶的自身策略存在Deny语句阻止了任务角色的访问，也会导致权限问题。检查桶策略，确保没有针对该任务角色的拒绝规则。

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