GitHub Actions 要求在 fork-origin PR 上使用 secrets。

Question

我们组织的GitHub存储库中有一个函数代码，应该被编译并部署在AWS Lambda函数中，并产生预期的输出。我们正在尝试使用GitHub操作将其实现为CI/CD流水线中的集成测试。我们希望每次创建新的PR时都运行此操作，以确保包含的代码更改不会导致任何回归测试失败。

以下是GitHub操作的预期运行方式：

1. 使用aws-actions/configure-aws-credentials来假定由OIDC连接器支持的角色，在幕后进行处理，其中ROLE_ARN作为秘密传递。
2. 构建代码并使用最新代码更新AWS Lambda函数
3. 调用Lambda函数
4. 将步骤3的输出与预先确定的预期输出进行比较
5. 根据第4步中的比较通过或失败集成测试

（理想情况下，我们还希望将其扩展到在每次执行时创建具有自动生成名称的新Lambda函数，并在执行完成后清理它，但这与问题陈述无关。）

我们知道GitHub的最佳实践建议不要在派生的PR上共享组织机密，因为这会打开恶意行为者使用脚本注入攻击的可能性。（参考 - GitHub Actions的安全加固）即使我们设置了一个操作，这些机密也不会在派生源PR的工作流中初始化。

那么，我们需要知道如何实现我们在这里尝试实现的等效方式的推荐方法是什么？因为这可能是社区遇到的最常见的用例之一。

我们还尝试查看环境机密是否与存储库机密有所不同，但事实证明，在派生源PR中，没有任何机密（包括环境机密）被传递。

为什么我们不能有一个手动批准支持的工作流程（类似于环境），其中批准人首先确保相应的GitHub操作工作流没有更改为危险操作（如注入），然后才运行集成测试？

更新 3/6：事实证明，除了传递机密之外，fork-origin PRs 还有另一个缺点，即无法将 id-token 的权限设置为 write，最多只能设置为 read。（参考 - 自动令牌身份验证）

- Akshay Rane

Answer 1

如果您正在使用带有分支的私有存储库，您可以启用选项"从拉取请求发送写入令牌到工作流"，这允许来自分支的拉取请求使用具有写入权限的GITHUB_TOKEN。如果您的组织尚未这样做，可能需要在中心位置启用此功能以允许使用。

您还应该"要求批准分叉拉取请求工作流程"，以确保来自没有写入权限的协作者的拉取请求上运行的工作流程将由具有写入权限的某人审核和批准后再运行。

- timmeinerzhagen