continuous-integration - 用于私有(private)项目的 Gitlab.com CI

Question

总结 :我们有一个关于 Gitlab.com CI 用于私有(private)项目的文档的担忧

注意:这是引用 Gitlab.com(和 不是 自托管 gitlab)

关注 :我们遇到了这个链接，https://docs.gitlab.com/ee/ci/runners/#be-careful-with-sensitive-information

我的解读 : 不建议在 Default Gitlab CI Runners 中构建私有(private)项目

解释是否有效？以及在多大程度上担心？

您认为这方面的最佳做法是什么？

问题 :

在私有(private)项目中使用 Gitlab.com Shared Runners for CI 可以吗？

我们的解决方案 :如果且仅当我们需要替代方案时(为此的 POC 已成功实现)

我们创建了一个 EC2 实例(私有(private)盒子)

将 Gitlab Runner 安装到盒子

将 EC2 实例连接到 Gitlab

从项目设置中禁用共享运行器

在 CI 运行时，它成功地将请求发送到我们的 EC2 实例

https://gitlab.com/gitlab-org/gitlab/-/issues/215677

Answer 1

短 :
我的解释是错误的。 Gitlab.com 是完全安全的 .引用的文档不适用于此用例。

阅读来自 Gitlab.com 的回复:https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25468#note_333854812

回复报价:

The Shared Runners on GitLab.com are isolated VM's that are provisioned for each CI job and removed after job execution. This is documented here. The documentation that you reference is actually referring to the situation where as a user you are now setting up and managing your own Runners. This is actually what you have done in the Our Solution section. So the security concern is that on your EC2 instance, if the Runner is configured to use the Shell executor for example, then any user in your organization that can execute CI jobs on the Runner on that EC2 instance is now able to execute a script which has full access to the filesystem on the EC2 instance. So this is why on GitLab.com we always create new isolated VM's for each job.