Gitlab Runner 无法访问 Gitlab 自托管实例

Question

我们在 Google Compute Engine 实例上安装了自托管的 Gitlab Enterprise。此实例受防火墙保护，因此只有我们的员工才能访问服务器。

当我们部署 Kubernetes 集群（使用 Gitlab CI）时，运行者无法访问 GitLab，因此不会启动 CI 作业。

我可以手动将 Google Kubernetes 实例的外部 IP 地址添加到我们的 GitLab 防火墙（GCP 防火墙允许所选 IP 范围的所有协议和端口），然后它就会工作。但是因为我们有不断变化的 Kubernetes 实例（以及抢占实例）的数量，我们必须每天手动执行此操作。

这不是最佳情况。我已经尝试添加内部 IP 范围（10.132.0.0/20、10.0.0.0/8、10.56.0.0/14），但这不是解决方案。如果不指定确切的实例 IP，运行者仍然无法访问 gitlab 服务器。

我错过了什么？

Answer 1

GKE 节点在 GCE 平台中显示为 VM 实例。它们由主节点管理，如果它们被认为不健康，可以（由 kube-controller）删除。删除后，它们将被重新创建。因此，IP 地址是临时的。使用每个 VM 实例的外部 IP 地址将非常具有挑战性，因为 IP 地址一直在变化。这不是一个可行的解决方案。

一种解决方法是充分利用NAT Gateway。来自 GKE 节点的所有出站流量都将路由到充当 NAT 网关的特定 VM 实例。然后，您将只有 1 个静态 IP 地址，即NAT Gateway 的外部 IP 地址。

然后，您将拥有一个可以添加到防火墙规则的静态 IP 地址。

Answer 2

三年后，您可能会受益于 GitLab 14.1（2021 年 7 月）

但是，仅适用于高级和终极产品，而不是免费版本：

Kubernetes 集群的 CI/CD 隧道

Kubernetes 集群的 CI/CD 隧道

到目前为止，将 Kubernetes 集群连接到 GitLab CI/CD 需要用户向 GitLab 开放他们的集群。
出于安全考虑，一些组织不鼓励在外部开放他们的防火墙。

GitLab 现在附带一个 CI/CD 隧道，它使用 GitLab Kubernetes Agent 将 GitLab Runner 与您的 Kubernetes 集群连接起来。这支持通用的 GitOps 工作流程，其中部署逻辑可以在管道中进行编码。

您和您的团队可以通过kubectl、helm、kpt、tanka 或其他任何方式安全地使用您喜欢的工具来运行部署本身，而无需担心安全问题。

要使用隧道，请在 CI/CD 管道中定义 kubecontext 以连接您的代理。为了简化这个过程，我们计划在未来的迭代中将automatically inject the kubecontext 引入 CI/CD 环境。

目前只有配置了代理的项目支持 CI/CD 隧道，但我们正在处理 adding group-level support。您可以安全地开始在 GitLab SaaS 和自我管理实例上使用隧道。

请参阅 Documentation 和 Epic。

---

还有GitLab 14.5（2021 年 11 月）

使用 CI/CD 隧道进行细粒度权限控制

对大多数公司而言，确保集群的访问安全至关重要。 GitLab Kubernetes 代理的 CI/CD 隧道支持从 GitLab CI/CD 内安全访问集群。

到目前为止，Tunnel 继承了集群中已安装代理的服务帐户的所有权限。
许多用户需要更严格的权限控制，最好是在用户或工作级别。

在 GitLab 14.5 中，我们很高兴发布通用访问模拟和 CI/CD 作业模拟。这些模拟可以在 Agent 配置文件中指定，并且可以使用 Kubernetes RBAC 规则来管理模拟的帐户权限。

请参阅 Documentation 和 Epic。