Gitlab Runner无法访问Gitlab自托管实例
Gitlab Runner can't access Gitlab self-hosted instance
我们在 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，runners 仍然无法访问 gitlab 服务器。
我错过了什么？
GKE 节点在 GCE 平台中显示为 VM 实例。它们由主节点管理，如果它们被认为不健康，可以（由 kube-controller）删除它们。一旦删除，它们就会被重新创建。因此，IP 地址是临时的。由于 IP 地址一直在变化，因此使用每个 VM 实例的外部 IP 地址将非常具有挑战性。这不是一个可行的解决方案。
一种解决方法是充分利用 NAT Gateway. All outbound traffic from the GKE nodes will be routed to a specific VM instance that would act as a NAT Gateway. You would then have only 1 static IP address which is the external IP address of the NAT Gateway。
然后您将拥有一个可以添加到防火墙规则的静态 IP 地址。
三年后，您可能会受益于 GitLab 14.1（2021 年 7 月）
但是，仅适用于高级和终极产品，不适用于免费版本：
CI/CD Tunnel for Kubernetes clusters
CI/CD Tunnel for Kubernetes clusters
Until now, connecting Kubernetes clusters to GitLab CI/CD required users to open up their clusters towards GitLab.
Some organizations do not encourage opening up their firewall externally due to security concerns.
GitLab now ships with a CI/CD Tunnel that connects GitLab Runners with your Kubernetes cluster using the GitLab Kubernetes Agent. This enables versatile GitOps workflows where the deployment logic can be coded in the pipeline.
You and your team can safely use your preferred tool to run the deployment itself using kubectl, helm, kpt, tanka, or anything else without security concerns.
To use the tunnel, define the kubecontext in your CI/CD pipeline to connect with your agent. To simplify this process, we plan to automatically inject the kubecontext into the CI/CD environment in a future iteration.
The CI/CD tunnel is currently supported only from the project where the agent was configured but we are working on adding group-level support. You can safely start using the tunnel on GitLab SaaS and self-managed instances.
See Documentation and Epic.
和GitLab 14.5（2021 年 11 月）
Fine grained permissions control with the CI/CD tunnel
Keeping your clusters’ access safe is paramount for most companies. The CI/CD Tunnel for the GitLab Kubernetes Agent enables secure access to the cluster from within GitLab CI/CD.
Until now, the Tunnel inherited all the permissions of the service account of the installed agent in the cluster.
Many users need stricter permission controls, preferably at the user or job level.
In GitLab 14.5, we are pleased to release a generic access impersonation and a CI/CD job impersonation. These impersonations can be specified in the Agent configuration file, and the impersonated account permissions can be managed using Kubernetes RBAC rules.
See Documentation and Epic.
我们在 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，runners 仍然无法访问 gitlab 服务器。
我错过了什么？
GKE 节点在 GCE 平台中显示为 VM 实例。它们由主节点管理，如果它们被认为不健康，可以（由 kube-controller）删除它们。一旦删除，它们就会被重新创建。因此，IP 地址是临时的。由于 IP 地址一直在变化，因此使用每个 VM 实例的外部 IP 地址将非常具有挑战性。这不是一个可行的解决方案。
一种解决方法是充分利用 NAT Gateway. All outbound traffic from the GKE nodes will be routed to a specific VM instance that would act as a NAT Gateway. You would then have only 1 static IP address which is the external IP address of the NAT Gateway。
然后您将拥有一个可以添加到防火墙规则的静态 IP 地址。
三年后，您可能会受益于 GitLab 14.1（2021 年 7 月）
但是，仅适用于高级和终极产品，不适用于免费版本：
CI/CD Tunnel for Kubernetes clusters
CI/CD Tunnel for Kubernetes clusters
Until now, connecting Kubernetes clusters to GitLab CI/CD required users to open up their clusters towards GitLab.
Some organizations do not encourage opening up their firewall externally due to security concerns.GitLab now ships with a CI/CD Tunnel that connects GitLab Runners with your Kubernetes cluster using the GitLab Kubernetes Agent. This enables versatile GitOps workflows where the deployment logic can be coded in the pipeline.
You and your team can safely use your preferred tool to run the deployment itself using
kubectl,helm,kpt,tanka, or anything else without security concerns.To use the tunnel, define the
kubecontextin your CI/CD pipeline to connect with your agent. To simplify this process, we plan to automatically inject thekubecontextinto the CI/CD environment in a future iteration.The CI/CD tunnel is currently supported only from the project where the agent was configured but we are working on adding group-level support. You can safely start using the tunnel on GitLab SaaS and self-managed instances.
See Documentation and Epic.
和GitLab 14.5（2021 年 11 月）
Fine grained permissions control with the CI/CD tunnel
Keeping your clusters’ access safe is paramount for most companies. The CI/CD Tunnel for the GitLab Kubernetes Agent enables secure access to the cluster from within GitLab CI/CD.
Until now, the Tunnel inherited all the permissions of the service account of the installed agent in the cluster.
Many users need stricter permission controls, preferably at the user or job level.In GitLab 14.5, we are pleased to release a generic access impersonation and a CI/CD job impersonation. These impersonations can be specified in the Agent configuration file, and the impersonated account permissions can be managed using Kubernetes RBAC rules.
See Documentation and Epic.