Connecting Gitlab to your Azure Kubernetes cluster

Gitlab allows you to provide details of your existing Kubernetes cluster.

In return, it offers an ever-increasing series of benefits for doing this, as part of Gitlab’s drive to become your main hub for every stage from “idea to production”.

Benefits of enabling this integration include:

  1. Links to logs, monitoring, terminals and more in Gitlab’s UI. Nice.

First you need to setup your cluster. I spun up a cluster using the managed ‘Azure Kubernetes Service’ available from the Azure Portal UI. I chose to leave RBAC disabled as Gitlab is a couple of months away from properly supporting this superior authentication method. I did however add ‘Http application routing’ so that Azure would give me an automatic domain name for my cluster, making testing and troubleshooting easier.

Next, I waited for the cluster to deploy. Waiting is important here! I’ve got my Gitlab setup into a mess in the past by trying to use connect to my cluster before it was ready.

To do the actual connection, I followed the steps here:

Which add some Azure specific details to on top of those from Gitlab’s docs:

The steps are:

1 — In the Azure portal open the cloud cli, or run your local Azure cli.

2 — Run this, substituting the name of your resource group and cluster

az aks get-credentials --resource-group <resource-group-name> --name <kubernetes-cluster-name>

You should see “Merged “kubernetes-cluster-name” as current context in /home/yourname/.kube/config”

3 — Inspect this config file. I used cat /home/yourname/.kube/config It can be a bit confusing, especially if there’s info for more than one cluster in there.

4 — Go to the Gitlab UI at

5 — For ‘Kubernetes cluster name’ give it the name of the cluster you created in Azure.

6 — Leave environment scope as a * if you’re unsure; that makes this the default cluster for gitlab.

7 — Look in the config file from Azure for something like this:

name: yourcluster

That’s the api url of your cluster. Paste it into gitlab.

8 — Just above that url is a ‘certificate authority data’ field, a huge blob of gibberish. Copy that blob (upto and including the last ==). Go to Go to and paste the blob in and push the decode button (or do something similar more securely locally). Your decoded version should begin “BEGIN CERTIFICATE“. Paste the whole of the decoded blob into Gitlab’s ‘CA Certificate’ field.

9 — The last section in the config file is called ‘users’. Find the user relevant to your cluster, and get the token value that is their last property (separated from their name by many lines of gibberish).

10 — Enter the name of your repo as the namespace on Gitlab (it’s a reasonable choice but you could use anything; the namespace is used to isolate different sets of kubernetes resources).

Once you save Gitlab’s form, you should see the cluster management pageon Gitlab.

So far we’ve just told Gitlab about our cluster. It hasn’t actually tried to connect to it. In order to test our connection, let’s get Gitlab to install Helm on the cluster (I think this is also a prerequisite for Gitlab installing other apps there).

Press the install button next to “Helm Tiller”. The button spins. Nothing happens. Wait … the button says “Installing”. Hopefully it will then say “Installed”.

Congratulations, you’ve connected Gitlab with an Azure Kubernetes cluster.