云上开发环境的凭据治理：临时 AK/SK 该给到什么粒度？

一次在云上开发空间里点"同意"的经历，让我重新看了一遍自己的 AK/SK 使用习惯。这篇把当时的思考整理成一套可以直接照着做的凭据治理清单。

一、一个很常见的弹窗

第一次进入 AI 开发者空间时，页面上弹出一段授权说明，大意是：

• 是否同意把临时访问凭据（AK/SK）同步到 AI 开发环境，免去手动配置；
• 凭据只存在沙箱环境，不上传到第三方；
• 该临时凭据拥有当前登录用户对应的 IAM 全部权限，请合理规划账号权限。

三句话，把云上开发环境最核心的一个安全取舍讲清楚了：为了"开箱即用"，我们把凭据直接塞进了执行环境。

这个设计本身没有问题——否则每次都要手动 export 一遍，体验会碎成一地。但"拥有全部权限"这半句值得单独拎出来讨论，因为在 AI 开发空间这个场景里，凭据的暴露面比传统开发机大得多。

二、为什么这个场景风险更高

1. 执行主体变了

传统开发机上，敲命令的是我自己。而在 AI 开发空间里，执行命令的是一个 Agent：我描述需求，它决定跑哪条命令、装哪个依赖、请求哪个地址。中间层层转述，任何一层理解偏差，动作就已经发生完了。

2. 依赖引入变多

Agent 为了完成任务，会自然而然地 pip install、npm i、curl 一些脚本下来跑。这些依赖的安装脚本在后置阶段以当前环境身份执行，而当前环境里躺着什么？一份 IAM 全权限凭据。

3. 环境生命周期不透明

体验版容器三小时后释放，但释放前的这三小时里，环境里发生了什么、凭据被哪些进程读到过，通常没人记得清。

一句话总结：当执行权交给模型，凭据的权限边界就该比人手动操作时收得更紧，而不是更松。

三、四条可以直接落地的动作

动作一：开发环境只给子用户，不给主账号

主账号（华为账号）是最高权限，且通常绑着计费、实名、企业认证等不可逆操作。把它丢进任何自动化环境都是不划算的。

正确做法是在 IAM 里建一个专用子用户，例如 dev-sandbox，给它独立的登录凭证，主账号只用来做权限审批。

动作二：用策略把权限压到"够用"

"够用"不是拍脑袋，可以从三个维度收紧：

对纯体验、纯学习场景，一个"只读 + 指定 OBS 目录可写"的子用户，能覆盖 90% 的需求。

动作三：优先 STS 临时凭据，并盯住有效期

STS 临时凭据有三个天然优势：有效期短、可携带会话策略、到期自动失效。在开发空间里能拿到临时凭据时，就不要用长期 AK。

拿到之后，建议顺手做两件事：

# 1. 确认环境变量里到底注入了什么（不要 echo 完整值）
env | grep -iE 'ak|sk|token' | sed 's/=.*/=<redacted>/'

# 2. 确认凭据文件权限不是全员可读
ls -l ~/.aws ~/.huaweicloud 2>/dev/null
chmod 600 ~/.huaweicloud/credentials 2>/dev/null

第一行命令是自查习惯：先看清环境里有什么，再决定要不要在里面跑别人的脚本。

动作四：审计必须开，且要会看

• 打开云审计服务（CTS），至少保留开发账号的凭证类操作记录；
• 对"创建/删除 AK"、"策略变更"、"跨区域访问"这三类事件设置告警；
• 定期拉一次 AK 使用记录，重点看有没有从非常用 IP、非常用地域发起的调用。

审计的价值不在于"出事之后能查"，而在于出事之前你会因为有人在看而少做一步。

四、一张出门检查清单

在把凭据交给任何一个自动化环境之前，我会过一遍这七条：

1. 用的是子用户，不是主账号？
2. 策略里有明确的服务白名单，而不是 *？
3. 资源范围收敛到了具体项目，而不是整个账号？
4. 凭据是 STS 临时的，且有效期可以接受？
5. 环境里没有留下长期 AK 文件？
6. 云审计已开启，凭证类事件有告警？
7. 这个环境里跑的东西，是不是我真的愿意让它拥有这些权限？

七条都打勾，再点"同意"。

五、结语

AI 开发空间把"从想法到跑起来"的路径压缩到了几分钟，这是实打实的效率提升。但效率提升的另一面，是决策被压缩——弹窗上那句"拥有全部权限，请合理规划账号权限"，其实是把本该由平台做的收口，交回给了使用者。

平台把选择权给了我们，那我们至少要把这个选择做对一次，然后把它固化成习惯。

本文基于个人在 AI 开发者空间中的实际使用体会整理，所涉权限配置以华为云 IAM 官方文档为准。