Agent for Kubernetes with Gitlab behind a firewall

The “new” agent for Kubernetes solves the problem when the Kubernetes cluster is behind a firewall and you want to be able to deploy to it. We have a reversed configuration. We run a Kubernetes cluster that is available via a public IP address, but our Gitlab on-premise installation is only available within the company (or via VPN). The deprecated certificate-based integration worked fine for us, but this feature will be removed with Gitlab 17.0.

What’s the best way to move forward with this? We rather not open up Gitlab to the internet for security reasons. We may need to create a site-to-site VPN from the Kubernetes cluster to our Gitlab server, but that’s quite a hassle. Another options is to only open wss://gitlab.example.com/-/kubernetes-agent/ to the public, but that’s still a risk.

Are there any other options that I could think of?

You could create a rule on the firewall to only allow the source address from the Kubernetes cluster connecting to your Gitlab. That way you are only opening the connection for that particular IP and not the entire internet to access your Gitlab. You can use egress to fix all communications from one public IP from all servers within the cluster. Or add all IP’s from all the servers in the cluster to the source address to allow contact with your Gitlab. Egress though is better assuming you have a free IP to use for that.

@iwalker That’s a good idea. Our Kubernetes clusters have fixed IPs.