概要: 我们对Gitlab.com私人项目的CI文档有一个关注点。
注：这里指的是Gitlab.com（和 不 自主托管的gitlab)
关注: 我们遇到了这个环节。https:/docs.gitlab.comeecirunners#be-careful-with-sensitive-information。
我的理解: 不建议在默认的 Gitlab CI Runners 中建立私人项目。
疑问:
我们的解决方案: 如果而且只有如果我们需要一个替代方案(POC已成功实施)
我们创建了一个EC2实例（一个私人盒子
在盒子上安装了Gitlab Runner。
连接EC2实例到Gitlab。
从项目设置中禁用共享运行器
在CI运行时，它成功地将请求发送到我们的EC2实例。
短文:我的解释是错误的。Gitlab.com是完全安全的. 引用的文档不适合这个用例。
阅读Gitlab.com的回复。https:/gitlab.comgitlab-orggitlab-runner-issues25468#note_333854812。
引用回复的内容。
GitLab.com上的共享运行器是一个隔离的虚拟机，为每个CI作业提供，并在作业执行后删除。这里有相关的文档。 你提到的文档其实是指作为用户，你现在要设置和管理自己的Runners的情况。这实际上是您在 "我们的解决方案 "部分所做的事情。所以安全问题是，在 EC2 实例中，如果 Runner 被配置为使用 Shell 执行器，那么您的组织中任何能够在 EC2 实例中的 Runner 上执行 CI 作业的用户现在都能够执行一个完全访问 EC2 实例中文件系统的脚本。 所以这就是为什么在GitLab.com上，我们总是为每个作业创建新的隔离虚拟机的原因。