如何通过默认最小权限强化GitHub Actions权限
内容提要
本文介绍如何为GitHub Actions工作流设置最小权限以降低安全风险。默认工作流权限过宽，可能被攻击者利用。建议先审计工作流实际需求，设置只读默认权限，仅在特定作业（如发布）添加写权限，并使用OIDC获取云访问凭证。最后验证工作流在受限权限下仍能正常运行。
延伸解读
权限过宽的隐患
工作流权限过宽往往不易察觉，因为流程仍能正常运行，直到安全审查或事故才暴露问题。攻击者可能利用过宽的令牌权限进行未授权操作，扩大攻击面。最小权限原则能有效降低风险，但需要先明确每个作业的实际需求。
审计与拆分
实施最小权限前，先审计工作流的具体操作，区分读、写需求。对于复杂工作流，可能需要先拆分作业，使权限边界清晰。例如，测试作业通常只需读取代码，而发布作业才需要写入权限。通过作业级权限设置，避免全局放宽。
OIDC替代长期凭证
当工作流需要访问云资源时，使用OIDC获取短期令牌，避免在仓库中存储长期凭证。这减少了凭证泄露的风险，但需正确配置OIDC信任关系。文章强调，OIDC并非万能，仍需结合代码审查和秘密扫描。
验证与权衡
收紧权限后，必须验证工作流仍能正常运行，并确保被移除的权限确实被阻止。文章指出，最小权限会增加初期配置成本，但换来更清晰的安全边界。若第三方操作需要额外权限，应审查该操作本身，而非简单放宽工作流权限。
Q&A
为什么需要为GitHub Actions工作流设置最小权限？
因为默认的工作流权限过宽，可能被攻击者利用，导致仓库被修改、令牌被滥用或影响范围扩大。最小权限可以降低安全风险，减少攻击面。
如何审计一个GitHub Actions工作流实际需要的权限？
首先列出工作流执行的操作，然后根据操作类型判断需要的权限。例如，克隆仓库和运行测试通常只需要contents: read，创建release需要contents: write，发布包需要packages: write，通过OIDC请求云凭证需要id-token: write。
在GitHub Actions中，如何设置默认的最小权限？
在工作流文件的顶层添加permissions块，并设置为contents: read，这样默认情况下工作流只能读取仓库内容，没有额外的写权限。
如果某个作业需要写权限，应该怎么处理？
只在该作业级别添加写权限，而不是扩大整个工作流的权限。例如，在release作业中添加permissions: contents: write，这样其他作业仍然保持只读权限。
为什么建议使用OIDC而不是长期凭证来获取云访问权限？
因为OIDC允许作业在运行时请求临时令牌，避免了在仓库中存储长期云密钥，从而降低了凭证泄露的风险。
如何验证工作流在最小权限下仍然正常工作？
运行工作流并确认预期的作业成功，同时故意测试一个需要被移除权限的操作，确保它失败而不是静默成功。检查工作流日志，确认请求的权限范围正确。
最小权限设置可能遇到哪些限制或问题？
对于包含多种操作的工作流，可能需要先拆分工作流才能清晰设置权限。此外，最小权限不能替代代码审查和秘密扫描，而且第三方actions可能需要比预期更宽的权限，此时需要审查action本身。
