How to set up confidential Gitlab

Challenge

Relying on online platforms such as GitHub to manage sensitive source code is convenient, but also comes with security and compliance implications. In essence, users of such offerings have no way of telling who is able to access their repositories. Hackers or malicious insiders could gain access to private repositories or bugs in the platform's own code could lead to data leaks.

To address such threats, companies often resort to running GitHub Enterprise or its competitor GitLab on-prem in a self-managed way. However, maintaining on-prem infrastructure is typically costly, comes with its own security challanges, and is often not even an option.

Solution

Confidential computing provides a cost-effective alternative to on-prem deployments. It is a groundbreaking technology that ensures that data is always encrypted, even during processing. If applied correctly, confidential computing can shield even complex applications from the cloud infrastructure. Not even system administrators, cloud provider employees or privileged attackers can access workloads protected this way. And this property can even be verified remotely. Basic confidential-computing features are readily available on major clouds like Azure and GCP. However, these basic features cannot protect complex and scalable applications like GitHub or GitLab.

For this, you need a solution like Constellation. Constellation is an open-source software that protects entire Kubernetes deployments end-to-end with confidential computing on public clouds. In essence, Constellation can shield and runtime-encrypt any application that can run on Kubernetes. Thus, with Constellation, you can run a complex source-code management system like GitHub Enterprise or GitLab on the public cloud, while having the assurance that the code is always encrypted and cannot be accessed by the cloud provider or attackers coming through the infrastructure.

Technical details

Constellation ensures that all components of the K8s cluster run in runtime-encrypted and isolated CVMs. This ensures that data written to cloud storage by databases is automatically encrypted, and the cryptographic keys for this data are generated and managed within the CVMs, all this without any additional coding from the developers. Constellation also verifies the integrity and authenticity of all CVMs and ensures that they are running the same "good" Constellation node image. This means that all data leaving the CVMs remains encrypted.

For example, when using databases like Redis or PostgreSQL, the data they write will be encrypted. After running the Constellation init command, you can be confident that you are communicating with an end-to-end confidential cluster via kubectl. For more information, please see the Constellation docs.

Read on for a more detailed walkthrough of the installation process.

Tutorial: How to install Gitlab on Constellation

Gitlab is a software that relies on PostgreSQL, NGINX, and Redis. However, it can be made confidential by using it in combination with Constellation on confidential computing enabled hardware, which is available in Azure, GCP, and AWS.

Live demo

You can see a demo of Confidential Gitlab in action at: https://gitlab.edgeless.systems/.

This instance syncs with the Constellation repo from GitHub.

Prerequisites and overview

In order to run Gitlab on Constellation, you will need:

A cloud provider with confidential computing capabilities (e.g. AWS, Azure, GCP)
A domain registrar to set up a domain name for your cluster
kubectl and helm installed on your machine

The process is composed of three key steps:

Setting up Constellation
Setting up the domain
Installing Gitlab via Helmchart

For the sake of clarity, we have written the instructions below as someone using Azure with a Godaddy registrar, however, this tutorial can be completed with any of the major cloud providers and a registrar of your choice.

Set up Constellation

After connecting to your cloud provider, download and install the Constellation CLI.

Once this is installed, create the constellation cluster:

This process is described in detail in the Constellation docs.

constellation config generate azure
constellation iam create azure --region=westus --resourceGroup=constellTest --servicePrincipal=spTest --update-config
constellation create -y
constellation init
export KUBECONFIG="$PWD/constellation-admin.conf"

You can now connect to the cluster with kubectl or other tools using the auto-generated constellation-admin.conf. The config ensures that the connection "confidential" and terminates inside the correct cluster. This ensures that no man-in-middle attack is possible.

Installing GitLab (automated)

In the case of our example set up (Azure with Godaddy) we've provided a custom Helm Chart that installs and configures the external-dns in the freshly created cluster.

While this can also be done manually through Gitlab through their official Helm Chart, we recommend using the Edgeless System's Helm Chart for a quicker overview of the entire process.

export GODADDY_API_KEY=<your creds here>
export GODADDY_SECRET_KEY=<your creds here>
export TARGET_DOMAIN=<your domain, e.g. gitlab.edgeless.systems>
export TLS_ISSUER_EMAIL=<your e-mail address>
export OWNER_ID= <your name here>

With your credentials in place, you can go ahead and run the necessary helm commands.

git clone https://github.com/edgelesssys/constellation-gitlab.git
cd constellation-gitlab
helm dependency update ./gitlab
helm upgrade gitlab-infra ./gitlab --install --namespace default --set infra.enabled=true --set apiKey=$GODADDY_API_KEY --set secretKey=$GODADDY_SECRET_KEY
helm upgrade gitlab-app ./gitlab --install --timeout 600s --set app.enabled=true --set gitlab.global.hosts.domain=$TARGET_DOMAIN --set gitlab.certmanager-issuer.email=$TLS_ISSUER_EMAIL --namespace gitlab --create-namespace

Installation complete

You've now set up your own confidential Gitlab! When the process has completed you should get a message with your Gitlab URL:

Hurray, GitLab on Constellation has been deployed!
It may take 5-10 minutes for all components to be set up completely.

Afterwards, you can access your GitLab instance here:
https://gitlab.example.test.com/

Your code or any notes or text you push to your repo are encrypted at all times. You can see Edgeless Systems' demo of the confidential Gitlab here.

What about user connections?

Users of the service should also have means to verify that the service is confidential and that it is the right instance they're talking to.

For browser-based connections, currently, the only way is to manually check the fingerprint of the TLS certificate. In the case of our demo instance of GitLab https://gitlab.edgeless.systems/ the SHA-256 fingerprint is:

CB C2 F9 23 7B 46 66 FC 5B 88 70 D5 3C 73 24 98 B4 EC 1D 12 EC 38 85 8C FA A6 44 B2 43 73 34 18

For Git CLI-based connections, things are simpler. By adding the following entry to our gitconfig file, we can ensure that Git always checks that the right certificate is present when talking to https://gitlab.edgeless.systems/:

[http "https://gitlab.edgeless.systems/"]
    pinnedPubkey = sha256//aZTzzCepU+Sa34+xkqyFGiWXG+/yHtF6Q5AgMMAjHhs=

With this in place, we know for sure that commands like git clone https://gitlab.edgeless.systems/edgelesssys/constellation.git or a corresponding git push will always go to the right confidential instance of GitLab and can't be diverted or intercepted by an attacker in control of the host of gitlab.edgeless.systems or the corresponding DNS entries.