短期凭证能完全替代长期密钥吗？

短期凭证不能在所有场景下完全替代长期密钥，但在 CI/CD 流水线中，它应当成为优先选择。两者的核心差异不只是“有效期长短”，而是风险是否能够被限制：长期密钥一旦进入 Git 历史、构建日志、环境变量、缓存或制品，可能被长期复制和反复使用；短期凭证即使发生泄露，也能通过自动过期缩短可利用窗口。

因此，短期凭证最适合承担运行时访问任务。流水线在任务开始时获取临时身份，按任务和环境授予最小权限，任务结束后自动失效，可以降低凭证残留带来的影响。但它并不会自动解决所有问题。如果凭证被打印到日志、写入制品，或被拥有运行器和日志读取权限的人员获取，泄露仍然成立；如果短期凭证权限过大，短暂的有效期也可能造成生产资源、数据库或制品发布链路的破坏。

不能简单替换的部分

系统仍可能需要一个受控的初始信任根，用于让流水线获得短期凭证、执行紧急恢复，或连接暂不支持临时身份的第三方服务。关键不在于保留多少长期密钥，而在于限制它们的使用边界：不应把长期密钥直接写入脚本或提交到仓库，而应存放在受控秘密存储中，缩小权限、限制可访问的任务，并建立轮换和审计机制。

判断替代是否成功，不能只看配置中是否出现了临时令牌，还要验证三个结果：非目标任务无法读取该身份；凭证不会出现在命令行、错误输出、缓存和制品中；旧凭证撤销后，流水线仍能稳定完成必要操作。只有同时满足这些条件，短期凭证才真正改变了风险模型，而不是把长期密钥换成了另一种更短的泄露物。

更准确的治理目标是“短期凭证优先、长期密钥最小化、所有凭证可追踪且能快速失效”，而不是追求一个脱离业务约束的绝对替代。