ARTICLE · 软件编程
如何在默认情况下通过最小特权强化 GitHub Actions 权限
一语总结本教程阐述了如何通过应用最小特权原则来保护 GitHub Actions，最小化权限以降低安全风险，同时保持工作流功能。
本文提供了一个逐步指南，用于强化 GitHub Actions 权限。它强调从最小权限开始，在作业之间划分读/写访问，使用 OIDC 获取云凭证而非长期保存的密钥，并通过有意的失败测试来验证受限权限。关键步骤包括审计工作流操作、在工作流层面设置默认权限、仅在需要时授予写入权限，以及验证工作流在受限访问下能够成功运行，而被阻止的操作会明确失败。教程还讨论了局限性，例如复杂工作流需要拆分，以及在第三方工具需要更广泛访问时进行特定操作的审查。
- 从最小权限开始，并为每个作业明确规定访问需求。
文章主张从最小必要权限开始（例如，测试作业使用 `contents: read`），仅对需要的特定作业授予写入权限，如发布或部署任务。
- 使用 OIDC 进行云访问，而不是存储长期凭证。
针对与云提供商交互的工作流，教程建议使用 OpenID Connect（OIDC）在运行时生成临时凭证，避免静态密钥的安全风险。
- 通过受控测试和失败案例验证权限更改。
该过程包括有意触发权限失败（例如，在没有访问权限的情况下尝试写入），以确认限制按预期工作，并且工作流在有效场景下仍能成功。
如何在默认情况下通过最小特权强化 GitHub Actions 权限
本文提供了一个逐步指南，用于强化 GitHub Actions 权限。它强调从最小权限开始，在作业之间划分读/写访问，使用 OIDC 获取云凭证而非长期保存的密钥，并通过有意的失败测试来验证受限权限。关键步骤包括审计工作流操作、在工作流层面设置默认权限、仅在需要时授予写入权限，以及验证工作流在受限访问下能够成功运行，而被阻止的操作会明确失败。教程还讨论了局限性，例如复杂工作流需要拆分，以及在第三方工具需要更广泛访问时进行特定操作的审查。
文章金句
"构建作业通常只需要读取权限，而发布作业可能只需狭窄的写入范围。
"更安全的做法是将每个作业视为独立的边界。
"最有力的信号是工作流在使用最小合理权限集时仍能通过，而仅在你有意移除所需权限时才会失败。