容器化TeamCity构建代理中，容器内构建步骤的boto3权限异常问询
这个问题我之前帮同事排查过，核心原因其实是Docker容器默认不会自动继承宿主TeamCity代理的AWS IAM角色凭证——虽然你的构建代理本身关联了权限足够的Task Role，但容器里的boto3进程根本没拿到正确的身份凭证，自然会触发UnauthorizedOperation错误。
下面分步骤帮你定位和解决：
第一步：先确认宿主代理的权限是正常的
先排除代理本身的问题：登录到运行TeamCity构建代理的AWS实例/ECS Pod上，手动执行一段简单的boto3测试脚本：
import boto3 ec2 = boto3.client('ec2') response = ec2.describe_instances(MaxResults=1) print(response)
如果这段脚本能正常返回结果，说明代理的Task Role确实生效，问题肯定出在Docker容器的配置上。
第二步：Docker容器无法获取凭证的常见原因&解决方法
1. 容器没挂载宿主的AWS凭证路径
AWS的Task Role凭证通常会挂载在宿主的特定路径下：
- 对于EC2实例：凭证文件默认在
/var/lib/aws/credentials - 对于EKS Pod（使用IAM ServiceAccount）：凭证在
/var/run/secrets/eks.amazonaws.com/serviceaccount/，同时需要环境变量AWS_WEB_IDENTITY_TOKEN_FILE和AWS_ROLE_ARN来指定
在TeamCity的「在Docker容器内运行步骤」配置中，你需要添加Volume挂载，把宿主的凭证目录映射到容器内的相同路径：
- 比如EC2场景：添加挂载项
/var/lib/aws/credentials:/var/lib/aws/credentials:ro（ro表示只读，更安全） - 比如EKS场景：添加挂载项
/var/run/secrets/eks.amazonaws.com/serviceaccount/:/var/run/secrets/eks.amazonaws.com/serviceaccount/:ro
2. 容器缺少必要的AWS环境变量
除了挂载凭证，还要确保容器能拿到关键的环境变量：
- 强制传递
AWS_REGION/AWS_DEFAULT_REGION，避免boto3因为区域配置错误触发额外问题 - 如果是EKS ServiceAccount场景，还要传递
AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token和AWS_ROLE_ARN=arn:aws:iam::你的账户ID:role/你的角色名
在TeamCity的Docker步骤设置里，找到「环境变量」部分，手动添加这些变量。
3. 容器用户没有凭证文件的读取权限
有时候宿主的凭证文件权限是644（只有root和文件所有者能读），而Docker容器默认用非root用户运行，导致无法读取凭证文件。
解决方法二选一：
- 在TeamCity的Docker步骤中，设置「运行参数」为
--user root，让容器以root用户运行（注意安全性，根据你的场景评估） - 调整宿主凭证文件的权限（比如改成
644确保其他用户可读，但不建议随便改宿主权限，优先用前一种方法）
4. 容器网络无法访问AWS元数据服务（EC2场景）
如果你的代理是EC2实例，Task Role的凭证是通过元数据服务（169.254.169.254）获取的，而Docker默认的bridge网络可能无法访问这个地址。
可以尝试在Docker运行参数中添加--net=host，让容器共享宿主的网络栈，这样就能直接访问元数据服务了。不过这种方式会打破容器的网络隔离，需要根据你的安全要求判断是否适用。
最后验证
调整完配置后，重新运行构建步骤，boto3应该就能正常获取到宿主代理的Task Role权限，执行DescribeInstances操作了。
内容的提问来源于stack exchange，提问作者tul
