AWS Credentials配置Action中角色链式调用的OIDC认证问题分析

问题背景

在aws-actions/configure-aws-credentials这个GitHub Action的最新版本中，开发者发现了一个关于AWS角色认证的重要行为变更。当工作流中第二次调用该Action进行AWS凭证配置时，系统错误地使用了用户凭证而非预期的OIDC方式进行角色切换。

问题现象

在连续调用configure-aws-credentials Action的场景下：

1. 第一次调用时能够正常使用OIDC方式获取角色凭证
2. 第二次调用时却意外地尝试使用前一次获取的临时凭证进行角色切换

这种行为导致认证失败，因为目标角色并未配置允许前一个角色进行切换的信任策略。

技术原理

该Action的核心功能是通过GitHub Actions的OIDC提供者与AWS IAM角色建立信任关系，获取临时安全凭证。正常情况下，每次调用都应通过GitHub的OIDC令牌直接与AWS STS服务交互，获取目标角色的凭证。

问题根源

问题源于项目最近的一次代码变更，开发团队在将Action输入参数设置为环境变量时，未排除Action自身的输出变量。这些输出变量中包含了前一次调用获取的临时凭证信息，导致后续调用错误地检测到了这些凭证并尝试使用它们进行角色切换。

解决方案

开发团队已确认并修复了此问题，具体措施包括：

1. 明确排除Action自身的输出变量不被作为环境变量传递
2. 确保每次调用都从干净的上下文开始
3. 维护OIDC认证流程的独立性

最佳实践建议

对于需要在工作流中多次切换AWS角色的场景，建议：

1. 检查每次角色切换的信任关系配置
2. 确保目标角色信任GitHub OIDC提供者而非中间角色
3. 考虑使用独立的步骤而非链式调用来完成复杂权限需求
4. 定期更新Action版本以获取最新修复

总结

这个案例展示了在CI/CD流程中管理云凭证时可能遇到的微妙问题。正确处理凭证传递和上下文隔离对于构建安全可靠的工作流至关重要。开发团队对此问题的快速响应也体现了开源社区在维护关键基础设施组件方面的效率。