Installation von Gitlab mit Reverse Proxy und alternativem SSH-Port

Installationen von Gitlab im Unternehmensumfeld sollten gehärtet sein. Absolut unterlässlich ist das frühstmöglichste Einspielen von Gitlab-Sicherheitsupdates. Zum Beispiel stopfte das kürzliche Update auf 16.8.1 stopfte eine Lücke mit einem Wert von 9,9 im CVSS. Daneben gibt es noch einige weitere Maßnahmen, die ergriffen werden können. Dieser Eintrag zeigt die Installation von Gitlab auf einem Debian-System mit dem Einsatz eines nginx-Reverse Proxys und alternativem SSH-Port.

Umgebung

Installiert wird in einem Umfeld mit zwei (V)Servern auf Basis von Debian 12. Natürlich kann die Installation auch auf einem Server erfolgen. Empfohlen wird jedoch eine Trennung zwischen Proxy und Anwendungsserver(n). Nicht selten kommen statt eines nginx-Revers Proxys auch fertige Appliances zum Einsatz. Die Verbindung zwischen dem Client-Browser wird dabei mit TLS verschlüsselt, die Verbindung zwischen dem Reverse Proxy und dem Gitlab-Server nicht. Letzteres wird oftmals noch so eingesetzt, hier darf aber auch auf einen Umstieg auf TLS nachgedacht werden.

Installation des Proxy-Servers

proxy-server: $ sudo apt-get update
proxy-server: $ sudo apt-get install nginx certbot python3-certbot-nginx
proxy-server: $ cd /etc/nginx/sites-enabled
proxy-server: $ sudo rm default
proxy-server: $ sudo touch ../sites-available/gitlab-proxy.conf
proxy-server: $ sudo ln -s ../sites-available/gitlab-proxy.conf .

Als nächstes wird die neu angelegte Konfigurationsdatei gefüllt:

# /etc/nginx/sites-available/gitlab-proxy.conf
server {
    server_name gitlab.meinedomain.de;

    location / {
      proxy_pass http://<INTERNE GITLAB-IP>:80$request_uri;
      proxy_read_timeout 60;
      proxy_connect_timeout 60;
      proxy_buffering off;
      client_max_body_size 100M;

      add_header       X-Served-By $host;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_set_header X-Forwarded-Scheme $scheme;
      proxy_set_header X-Real-IP $remote_addr;
    }
}

Danach wird ein von einer vertrauenswürdigen Stelle unterschriebenes X.509-Zertifikat erstellt und der Proxyserver neu gestartet.

proxy-server: $ sudo certbot --nginx -d blog.meinedomain.de
proxy-server: $ sudo service nginx reload

Wenn alles funktioniert hat, ist der Reverse-Proxy nun einsatzbereit. Es kann nun mit der Einrichtung des Gitlab-Servers gestartet werden.

Installation von Gitlab

Hierzu wird sich per SSH auf den internen Server eingeloggt. Danach erfolgt die Installation von Gitlab. Wenn man die EE-Version installiert, hat man später die Möglichkeit auf die Bezahlfeatures umzusteigen. Das ist mit der CE-Version nicht möglich. Das Herunterladen von Daten aus dem Internet und das Ausführen wie hier mit | sudo bash gezeigt, ist gefährlich und sollte nur von Quellen geschehen, denen man vertraut.

gitlab-server: $ sudo apt-get update
gitlab-server: $ sudo apt-get install -y curl openssh-server ca-certificates perl postfix
gitlab-server: $ curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
gitlab-server: $ sudo apt-get update
gitlab-server: $ sudo EXTERNAL_URL="https://gitlab.meinedomain.de" apt-get install gitlab-ee

Damit ist die Installation von Gitlab abgeschlossen. Wenn auch dies problemlos funktioniert hat, kann nun mit der Konfiguration von Gitlab fortgefahren werden.

Konfiguration von Gitlab

Gitlab muss nun so konfiguriert werden, dass es einmal kein https erwartet und zum anderen auf Port 80 hört. Auch die externe Domain muss eingetragen werden. Den SSH-Port kann man nicht in der gitlab.rb konfigurieren. Hier wird immer der serverweit eingestellte SSH-Port verwendet. Je nach Topologie und SSH-Zugriffssezenario empfehlen sich hier diverse Konzepte. In der Praxis bewährt hat sich ein Zugriff auf alle Server per SSH auf Port 22 entweder über einen Jumphost oder einem VPN über Wireguard. Für den Zugriff auf Gitlab kann dann in der Firewall ein dNAT von Port 20022 auf Port 22 auf dem Gitlab-Server konfiguriert werden. Die weiter unten erfolgende Einstellung mit dem Namen "gitlab_rails['gitlab_shell_ssh_port']" dient dazu, dass Links in der Weboberfläche von Gitlab ohne Änderung als Copy/Paste-Befehl auf dem Client ausgeführt werden können. Zum Anpassen der gitlab.rb-Datei:

gitlab-server: $ sudo nano /etc/gitlab/gitlab.rb

Dort müssen die folgenden Konfigurationszeilen angepasst werden:

# /etc/gitlab/gitlab.rb
external_url 'https://gitlab.meinedomain.de'
...
nginx['listen_port'] = 80
nginx['listen_https'] = false
...
gitlab_rails['gitlab_shell_ssh_port'] = 20022
...

Anschließen müssen die Konfigurationsänderungen wirksam gemacht werden. Danach ist das System voll einsatzbereit. Dennoch empfiehlt sich ein Neustart. Dann kann man direkt testen, ob nach einem Reboot (geplant oder ungeplant) alles funktioniert.

gitlab-server: $ sudo gitlab-ctl reconfigure