我有一个使用叉子模型的github动作的问题。
我使用叉子模型，需要在叉子工作流程中以叉子返回基本存储库中的拉动库来检查叉子存储库。 CI工作流程需要基本存储库的一些秘密。
当前设置：
-
基本存储库/主branch/.github/workflows/正确的工作流文件。
-
分叉存储库/主分支/.github/workflows/恶意修改文件以揭示秘密。
-
基本存储库中的操作设置：
- 从叉拉请求中运行工作流[是]
- 将写令牌发送到叉拉请求的工作流[no]
- 将秘密发送到工作流程表格叉拉请求[是]
观察行为/q：
- 我可以从分叉的主分支机构创建拉动请求 - ＆gt;基本主分支
- 使用叉子存储库中的文件，请求触发工作流程运行。这是一个问题，因为有人可以分叉分支并添加工作流程以揭示秘密。
-
aws-actions/configure-aws-credentials 在工作流程内可以使用AWS登录。这是一个问题，因为此操作需要权限：id-token：write 。据我了解，叉子的拉请不应授予工作流的任何写入权限。我在这里也担心安全。
有希望的行为：
我想实现的目标是，仍然允许从分叉存储库中提取请求来触发CI工作流，但是使用基本存储库中的文件而不是分叉的存储库。无论如何都可以吗？如果没有，有任何补救措施吗？
还希望检查我对仅授予分叉拉的请求的所谓阅读权限的理解。为什么 id-token：Write 权限似乎有效？工作流文件中的显式权限声明确实可以覆盖叉拉请求限制吗？
如果我误解重要的概念，则是第一次工作流用户深表歉意。
参考：预防pwn攻击
I have a question using github actions with a fork model.
I work with a fork model, where forked repository needs to be checked by CI workflows in a pull requests from the fork back to base repository. The CI workflows needs some secret from the base repository.
Current setup:
-
Base Repository/main branch/.github/workflows/correct workflow files.
-
Forked Repository/main branch/.github/workflows/maliciously modified files to reveal secrets.
-
Action settings in base repository:
- Run workflows from fork pull requests [yes]
- Send write tokens to workflows from fork pull requests [no]
- Send secrets to workflows form fork pull requests [yes]
Observed Behaviors/Q:
- I can create a pull request from forked main branch -> base main branch
- The request triggers workflow runs, using files from the FORKED repository. This is a problem because someone can fork the branch and add workflow to reveal secrets.
- The
aws-actions/configure-aws-credentials inside a workflow can log in with AWS. This is a problem because this action requires permissions: id-token: write. From what I understand, pull requests from forks should not grant any write permissions to workflows. I am concerned about security here as well.
Hopeful behavior:
What I want to achieve is, still allowing pull requests from forked repos to trigger CI workflows, but using files from the base repo instead of the forked repo. Is this possible in anyways? If not, any remedies?
Also want to check my understanding about the supposedly read only permission granted to forked pull requests. Why the id-token:write permission seems to work? Is it true that the explicit permission declaration in workflow files can override the fork pull request limitation?
Apologize if I misunderstand important concepts, first time workflow user.
Reference: prevent PWN attacks
发布评论
评论（1）
我无法提供保护一般证书的解决方案，但是我可以为AWS特定的凭证提出解决方法。
OpenID Connect您可以创建一个启用OpenID的IAM角色，
Trustgithub Action假设它。这是通过我们的各种GitHub行动来实现的。您可以在Github的文档中找到更多细节。
I'm unable to provide a solution to protect general credentials, however I can propose a workaround for AWS-specific credentials.
OpenID ConnectYou can create an IAM role that OpenID enabled, and
trustgithub action assume it. This was accomplished by a variety of our github actions.You can find more detail in github's docs.
https://docs.github.com/cn/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services