Gitlab agent-based Kubernetes integration

Still in the scope of exploring the cloud native ecosystem, and after presenting some routing and monitoring tools I would like to dwell on the deployment topic. Last year, Gitlab finalized the roll-out of a new integration method with Kubernetes and I think it deserves to be better known. It provided a security improvement to a situation in which I was confronted. In this article I will present the simple approach to integrate a CI server to a Kubernetes cluster and highlight a benefit of Gitlab solution.

Kubernetes integration, the straightforward way.

Here is a simple and intuitive method to trigger Kubernetes deployments from a continuous integration server.

A properly configured Kubernetes command-line interface (kubectl) is installed and available in the scope of the CI job runner. This CLI calls the Kubernetes API server using https to trigger deployments.

This is fine but what if the CI server and the Kubernetes cluster are not in the same corporate network ? The situation would be as shown below.

We now have a firewall between the CI job runner and the Kubernetes cluster API. Which means In order to for the CI job runner to reach the Kubernetes API server it has to cross a firewall. As a consequence this has to be configured with a new rule to allow incoming trafic from the IP address of the CI server through port 443. A security priciple states that the surface attack should be minimized. Here we are falling short.

Gitlab agent-based integration

Now here is the new Gitlab agent-based integration.

The pipeline runner does not directly call the Kubernetes cluster API. Instead, it calls the Gitlab Kubernetes API Proxy, that communicates through a web-socket with the Gitlab agent installed in the Kubernetes cluster, which ultimately calls the Kubernetes API.

With this architecture, the connexion beween the CI server and the Kubernetes cluster is initiated from inside the corporate network, when the agent is started. So adding firewall rule to incoming traffic is no more needed.

Not only does the agent-based architecture improves the security, but it also adds more logic to the cluster side, which is then able to pull the most recent versions of services instead of having them pushed by the CI server, in respect with the Gitops pattern.