Gitea SSL mit Apache als Reverse-Proxy

Um das Container-Registry-Feature in k8s zu verwenden, benötigen wir es über SSL.

Inhaltsverzeichnis

Wir möchten eine schöne und sichere Container-Registrierung hosten – um Docker-Images dort hinzupushen und unseren Kubernetes-Cluster diese aus der Registrierung zu pullen.
Also kam die Idee, Gitea über SSL zu verwenden.

Gitea hat bereits eine Container-Registrierung
Apache als TLS-terminierender Proxy fügt HTTPS zu unserem Gitea hinzu.
So fing es an… Rot CA, selbstsignierte Zertifikate…

Jede Registrierung hat ihre eigenen Geheimnisse

Wenn wir die Registrierung in Kubernetes benötigen

Leider funktioniert die in Kubernetes-Clustern von Kubespray erstellte Registrierung nicht für mich.

Um in sie zu pushen, müssen wir einen temporären Tunnel über kube-proxy erstellen
Nach dem Pushen in sie kann meine aktuelle Version des neuen Clusters keine Images aus dieser internen Registrierung pullen

Nachdem ich einige großartige zwei Abende damit verbracht habe, es zu beheben,
habe ich beschlossen, einfach die interne Container-Registrierung von Gitea zu verwenden, muss nur HTTPS-Zugriff darauf konfigurieren.

Ich werde es dennoch öffentlich machen, damit Docker und Kubernetes keine Docker-Logins durchführen müssen.
Vielleicht. Schauen wir, wie es weitergeht.

Testen, ob es funktioniert

Um zu testen, ob die Container-Registrierung uns passt, möchten wir in der Lage sein

ein Image dorthin zu pushen und
eine Deployment in Kubernetes aus diesem Image zu erstellen

sudo docker pull alpine:3.12.0
sudo docker images
sudo docker tag a24bb4013296 localhost:5000/rg/alpine:version.3.12.0
sudo docker push localhost:5000/rg/alpine:version.3.12.0

Jetzt xed alp1.yaml oder nano alp1.yaml, je nachdem, in welcher Stimmung du bist, und

apiVersion: apps/v1
kind: Deployment
metadata:
  name: alp-registry-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: alp-registry-test
  template:
    metadata:
      labels:
        app: alp-registry-test
    spec:
      containers:
        - name: alpine-test
          image: localhost:5000/rg/lpine:version.3.12.0
      imagePullSecrets:
      - name: registry-secret

Diese Datei ist hier zum Herunterladen verfügbar.
Dann erstellen wir diese Deployment:

kubectl create -f alp1.yaml
kubectl get pods

kubectl describe po alp-registry-test-5f5cb94b97-njsp2
# oder was auch immer Pod erstellt oder nicht erstellt wurde

Ja, ich weiß über diesen Abschnitt:

      imagePullSecrets:
      - name: registry-secret

registry-secret ist der Name des Geheimnisses, das Kubespray erstellt hat.

Aufräumen:

kubectl delete -f alp1.yaml

Wie

Eine Menge Dokumentation ist auf Gitea-Website: https-setup verfügbar

Und auf dieser Seite: https://docs.gitea.com/administration/reverse-proxies

Schritt 1 – Apache installieren und einfachen Testserver erstellen

Apache installieren

sudo apt install apache2

Überprüfen, was wir in der Firewall haben

sudo ufw status

Wenn die Firewall aktiv ist, denken Sie daran, welchen Port Sie über HTTPS exponieren möchten und erlauben Sie ihn. Standard Apache-Konfigurationen sind

sudo ufw app list

Wir könnten etwas wie folgendes sehen:

Verfügbare Anwendungen:
  Apache
  Apache Full
  Apache Secure
  OpenSSH

und um nur den Port 443 zu aktivieren, führen wir aus

sudo ufw allow 'Apache Secure'

Okay. Jetzt den Dienststatus prüfen

sudo systemctl status apache2

Als nächstes – einen einfachen virtuellen Server erstellen, um Apache zu testen

sudo mkdir /var/www/reg.homelab
sudo chown -R $USER:$USER /var/www/reg.homelab
sudo chmod -R 755 /var/www/reg.homelab
sudo nano /var/www/reg.homelab/index.html

Fügen Sie dort ein

<html>
    <head>
        <title>Willkommen bei reg.homelab!</title>
    </head>
    <body>
        <h1>Erfolg! Der virtuelle Host reg.homelab funktioniert!</h1>
    </body>
</html>

dann

sudo nano /etc/apache2/sites-available/reg.homelab.conf

und setzen Sie dort

<VirtualHost *:3080>
    ServerAdmin webmaster@localhost
    ServerName reg.homelab
    ServerAlias www.reg.homelab
    DocumentRoot /var/www/reg.homelab
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

dann deaktivieren Sie den Standardserver, aktivieren Sie diesen und prüfen Sie, wie es läuft

sudo a2ensite reg.homelab.conf
sudo a2dissite 000-default.conf
sudo apache2ctl configtest

Sieht etwas wie dies aus?

AH00558: apache2: Der vollständige Domain-Name des Servers konnte nicht zuverlässig bestimmt werden, 127.0.1.1 wird verwendet. Setzen Sie die 'ServerName'-Direktive global, um diese Nachricht zu unterdrücken.

dann

sudo nano /etc/apache2/apache2.conf

fügen Sie am Ende hinzu:

ServerName reg.homelab

Und das ist immer noch nicht das Ende! Jetzt müssen wir den Versuch, den Port 80 zu binden, entfernen

sudo nano /etc/apache2/ports.conf

setzen Sie dort

Listen 3030
...
Listen 443

Und jetzt

sudo systemctl restart apache2
sudo systemctl status apache2
journalctl -xeu apache2.service
curl localhost:3080

OK! Jetzt navigieren Sie zu :3080

Schritt 2 – Diesen Server in einen unsicheren Reverse-Proxy zu Gitea umwandeln

sudo nano /etc/apache2/sites-available/reg.homelab.conf

setzen Sie dort

<VirtualHost *:443>
    ServerAdmin webmaster@localhost
    ServerName reg.homelab
    ServerAlias www.reg.homelab
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
    ProxyPreserveHost On
    ProxyRequests off
    AllowEncodedSlashes NoDecode
    ProxyPass / http://localhost:3000/ nocanon
</VirtualHost>

Führen Sie einige Konfigurationsprüfungen durch

sudo apache2ctl configtest

Fügen Sie einige Apache-Module hinzu und starten Sie Apache neu

sudo a2enmod proxy proxy_http ssl
sudo systemctl restart apache2
sudo systemctl status apache2

OK, jetzt navigieren Sie zu oder curl

# Ja, es ist immer noch HTTP, aber auf dem Port 443
curl http://localhost:443
http://<Server_IP_Address>:443/

Schritt 3 – Selbstsigniertes Root-CA und Site-Zertifikat

SweetHome-RootCA.

CANAME=MostImportant-RootCA

# optional, erstellen Sie ein Verzeichnis
mkdir $CANAME
cd $CANAME

# generieren Sie ein AES-verschlüsseltes privates Schlüssel
openssl genrsa -aes256 -out $CANAME.key 4096

# erstellen Sie ein Zertifikat, 1826 Tage = 5 Jahre
openssl req -x509 -new -nodes -key $CANAME.key -sha256 -days 1826 -out $CANAME.crt -subj '/CN=My Root CA/C=AT/ST=Vienna/L=Vienna/O=MyOrganisation'

# erstellen Sie ein Zertifikat für den Dienst
MYCERT=reg.homelab
openssl req -new -nodes -out $MYCERT.csr -newkey rsa:4096 -keyout $MYCERT.key -subj '/CN=My Firewall/C=AT/ST=Vienna/L=Vienna/O=MyOrganisation'

# erstellen Sie eine v3 ext Datei für SAN-Eigenschaften
cat > $MYCERT.v3.ext << EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = reg.homelablab
DNS.2 = gitea.homelablab
IP.1 = 192.168.0.10
IP.2 = 192.168.0.11
EOF

openssl x509 -req -in $MYCERT.csr -CA $CANAME.crt -CAkey $CANAME.key -CAcreateserial -out $MYCERT.crt -days 730 -sha256 -extfile $MYCERT.v3.ext

Auf Maschinen, die auf gitea / Registrierung zugreifen

Registrieren Sie das Root-Zertifikat unter Linux:

sudo cp MostImportant-RootCA.crt /usr/local/share/ca-certificates
sudo update-ca-certificates

Registrieren Sie das Root-Zertifikat unter Windows:

Doppelklicken Sie auf die Datei MostImportant-RootCA.crt
Importieren Sie sie in den lokalen Benutzer
Wählen Sie Vertrauenswürdige Root-CA.
Wenn Sie nach einem Hinweis zu einem unvertrauenswürdigen Zertifikat gefragt werden – klicken Sie auf Ja

Wenn Git pull unter Windows über

Unable to resolve "unable to get local issuer certificate...

sagt, können Sie Git anweisen, die Windows-Netzwerkschicht zu verwenden, indem Sie

git config --global http.sslbackend schannel

Schritt 4 – Proxy mit selbstsigniertem Zertifikat sichern

https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html

Erstellen Sie ein selbstsigniertes Zertifikat, wenn Sie es in Schritt 3 nicht getan haben

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -subj "/CN=reg.homelab" \
  -addext "subjectAltName = DNS:reg.homelab" \
  -keyout /etc/ssl/private/apache-selfsigned-reg.homelab.key \
  -out /etc/ssl/certs/apache-selfsigned-reg.homelab.crt

Oder einfach von dem vorherigen Schritt übernehmen

sudo cp reg.homelab.crt /etc/ssl/certs/apache-selfsigned-reg.homelab.crt
sudo cp reg.homelab.key /etc/ssl/private/apache-selfsigned-reg.homelab.key

Nochmals, öffnen Sie die virtuelle Host-Konfiguration

sudo nano /etc/apache2/sites-available/reg.homelab.conf

Fügen Sie dort unten den SSL-Abschnitt mit den Zertifikaten hinzu

<VirtualHost *:443>
   ServerAdmin webmaster@localhost
   ServerName reg.homelab
   ServerAlias www.reg.homelab
   ErrorLog ${APACHE_LOG_DIR}/error.log
   CustomLog ${APACHE_LOG_DIR}/access.log combined
   ProxyPreserveHost On
   ProxyRequests off
   AllowEncodedSlashes NoDecode
   ProxyPass / http://localhost:3000/ nocanon
    
   SSLEngine on
   SSLCertificateFile /etc/ssl/certs/apache-selfsigned-reg.homelab.crt
   SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned-reg.homelab.key
</VirtualHost>

Überprüfen Sie die Konfiguration, starten Sie den Server neu, prüfen Sie den Status und navigieren Sie zu unserem Gitea über SSL

sudo apache2ctl configtest
sudo systemctl restart apache2
sudo systemctl status apache2

# goto: http://<Server_IP_Address>:443/
# oder
curl -k -v https://localhost

Der Browser wird vor dem selbstsignierten Zertifikat warnen

Ihre Verbindung ist nicht privat
Angreifer könnten versuchen, Ihre Informationen von reg.homelab zu stehlen (z. B. Passwörter, Nachrichten oder Kreditkarten). Erfahren Sie mehr
NET::ERR_CERT_AUTHORITY_INVALID

Aber wir ignorieren es fürs Erste, bis wir Let’s Encrypt verwenden.

Jetzt Kubernetes-Test

Machen Sie einige DNS-Einstellungen…

Auf jedem Kubernetes-Node:

sudo nano /etc/hosts

und fügen Sie dort hinzu

192.168.18.200 gitea.homelab
192.168.18.200 reg.homelab

Root-CA

Auf jedem Kubernetes-Node:

sudo cp SweetHome-RootCA.crt /usr/local/share/ca-certificates
sudo update-ca-certificates

Und jetzt neu starten

Geheimnis mit Registrierungsanmeldeinformationen erstellen

https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/

sudo docker login reg.homelab
kubectl create secret generic regcred --from-file=.dockerconfigjson=/home/rg/.docker/config.json --type=kubernetes.io/dockerconfigjson

oder

kubectl create secret docker-registry regcred --docker-server=your-registry-server --docker-username=your-name --docker-password=your-pword --docker-email=your-email

Neues Docker-Image und Kubernetes-Deployment

sudo docker pull alpine:3.12.0
sudo docker images
sudo docker tag a24bb4013296 reg.homelab/rg/alpine:version.3.12.0
sudo docker push reg.homelab/rg/alpine:version.3.12.0

Jetzt nano alp2.yaml, die Datei ist hier verfügbar

apiVersion: apps/v1
kind: Deployment
metadata:
  name: alp-registry-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: alp-registry-test
  template:
    metadata:
      labels:
        app: alp-registry-test
    spec:
      containers:
        - name: alpine-test
          image: reg.homelab/rg/alpine:version.3.12.0
      imagePullSecrets:
      - name: regcred

Diese Datei ist hier zum Herunterladen verfügbar:
Dann erstellen wir diese Deployment:

kubectl create -f alp2.yaml
kubectl get pods
kubectl describe po alp...