Agent-less GitLab integration with OpenShift

20. Apr 2022

As you know (and if you didn’t, now you do) GitLab has deprecated the certificate-based integration with Kubernetes in version 14.5, and it is expected that version 15 will disable it completely.

The official replacement to the (now legacy) certificate-based integration mechanism is the GitLab Agent, to be installed in your Kubernetes cluster, and providing a tighter integration between our two beloved platforms.

Well, hold on; things aren’t that easy. For example in our case, if we wanted to offer the GitLab Agent to our APPUiO Cloud users, we would run into two issues:

  • On one side, installing the GitLab Agent is more complicated and expensive, because it would run as another pod in the same namespace, consuming resources.
  • And on the other, we cannot install it cluster-wide, because of the admin permissions we have configured in this multi-tenant shared platform. Users would have to manage each and every GitLab Agent on their own, possibly having multiple agents deployed in several namespaces and GitLab repositories.

So, what’s a DevOps engineer to do? Well, here’s a simple, very simple solution; so simple that you might have never thought of it before: create your own KUBECONFIG variable in GitLab with a dedicated service account!

Here’s how it works using the OpenShift oc tool in your own system:

Create a service account in your OpenShift project:

oc create serviceaccount gitlab-ci

Add an elevated role to this service account so it can manage your deployments:

oc policy add-role-to-user admin -z gitlab-ci --rolebinding-name gitlab-ci

Create a local KUBECONFIG variable and login to your OpenShift cluster using the gitlab-ci service account:

TOKEN=$(oc sa get-token gitlab-ci)
export KUBECONFIG=gitlab-ci.kubeconfig
oc login --server=$OPENSHIFT_API_URL --token=$TOKEN

You should now have a file named gitlab-ci.kubeconfig in your current working directory; copy its contents and create a variable named KUBECONFIG in the GitLab settings with the value of the file (that’s under “Settings” > “CI/CD” > “Variables” > “Expand” > “Add variable”). Remember to set the “environment” scope for the variable and to disable the old Kubernetes integration, as the KUBECONFIG variable might collide with this new variable.

Tada! There are a few advantages to this approach:

  • It is certainly faster and simpler to setup for simple push-based deployments than by using the GitLab Agent.
  • It is also easier to get rid of deprecated features without having to change the pipeline or migrating to the GitLab Agent.

But there are a few drawbacks as well:

  • You don’t get all bells and whistles. It is reasonable to think that at some point the GitLab Agent will offer advanced features, such as access to pod logs from GitLab, monitoring alerts directly from the GitLab user interface, and many other things the old Kubernetes certificate-based integration could do. This approach does not provide anything like this.
  • The cluster’s API endpoint has to be publicly accessible, not behind any firewall or VPN; conveniently enough, the GitLab Agent solves exactly this problem.

If you are interested in GitLab and Kubernetes, join us next week in our GitLab Switzerland Meetup for more information about the GitLab Agent for Kubernetes, and afterwards for a nice apéro with like-minded GitLab enthusiasts!

Oh, and a final tip; if you find yourself having to log in to OpenShift integrated registry but you don’t have yq installed in the job’s image, you can use sed to extract the token from the $KUBECONFIG file:

sed -n 's/^\s*token:\s*\(.*\)/\1/ p' "${KUBECONFIG}" | docker login -u gitlab-ci --password-stdin "${OPENSHIFT_REGISTRY}"

Christian Сremer

Christian Cremer is a DevOps engineer in VSHN.

Contact us

Our team of experts is available for you. In case of emergency also 24/7.

Contact us