Gitea SSL avec Apache en tant que proxy inverse

Pour utiliser le registre de conteneurs dans k8s, il faut l'utiliser via SSL

Sommaire

Nous souhaitons héberger un registre de conteneurs sécurisé – pour pousser des images Docker là-bas et notre cluster Kubernetes pourra les récupérer à partir de ce registre.
Ainsi est venue l’idée d’utiliser Gitea sur SSL.

  1. Gitea possède déjà un registre de conteneurs
  2. Apache en tant que proxy terminant TLS ajoutera HTTPS à notre Gitea.
  3. C’est ainsi que cela a commencé… Création d’une CA, certificats auto-signés…

Chaque registre a ses propres secrets

Lorsque nous avons besoin du registre dans Kubernetes

Malheureusement, le registre de conteneurs créé par Kubespray dans le cluster Kubernetes ne fonctionne pas pour moi.

  • pour pousser vers celui-ci, il faut créer un tunnel temporaire via kube-proxy
  • après avoir poussé vers celui-ci, ma version actuelle du nouveau cluster ne peut pas récupérer d’images à partir de ce registre interne

Après avoir passé quelques soirées incroyables à essayer de le corriger,
j’ai décidé d’utiliser simplement le registre de conteneurs interne de Gitea, il suffit de configurer l’accès HTTPS à celui-ci.

Je le rendrai public de toute façon, donc Docker et Kubernetes n’auront pas besoin de faire aucune connexion Docker.
Peut-être. Voyons comment les choses se dérouleront.

Tester si cela fonctionne

Pour tester si le registre de conteneurs convient, nous souhaitons pouvoir

  • pousser une image là-bas et
  • créer un déploiement dans Kubernetes à partir de cette image
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

Maintenant xed alp1.yaml ou nano alp1.yaml selon votre humeur et

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

Ce fichier est disponible pour téléchargement Ensuite, création de ce déploiement

kubectl create -f alp1.yaml
kubectl get pods

kubectl describe po alp-registry-test-5f5cb94b97-njsp2
# ou quel que soit le pod créé ou non créé

Oui, je connais ce passage

      imagePullSecrets:
      - name: registry-secret

registry-secret est le nom du secret créé par Kubespray.

Nettoyage

kubectl delete -f alp1.yaml

Comment faire

Un certain nombre de documents sont disponibles sur le site Gitea : https-setup

Et sur cette page : https://docs.gitea.com/administration/reverse-proxies

Étape 1 - Installer Apache et créer un site de test simple

Installer Apache

sudo apt install apache2

Vérifier ce que nous avons dans le pare-feu

sudo ufw status

Si le pare-feu est actif, réfléchissez à quel port vous souhaitez exposer via HTTPS et autorisez-le. Les configurations Apache par défaut sont

sudo ufw app list

Nous pourrions voir quelque chose comme

Applications disponibles :
  Apache
  Apache Full
  Apache Secure
  OpenSSH

et pour activer uniquement le port 443, nous exécutons

sudo ufw allow 'Apache Secure'

ok. maintenant vérifier l’état du service

sudo systemctl status apache2

Ensuite, créer un serveur virtuel simple pour tester Apache

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

Mettre ceci

<html>
    <head>
        <title>Bienvenue sur reg.homelab !</title>
    </head>
    <body>
        <h1>Succès ! Le hôte virtuel reg.homelab fonctionne !</h1>
    </body>
</html>

ensuite

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

et mettre ceci

<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>

ensuite, désactiver le site par défaut, activer celui-ci et vérifier comment nous allons

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

vous voyez quelque chose comme ceci ?

AH00558: apache2: Impossible de déterminer de manière fiable le nom de domaine complet du serveur, en utilisant 127.0.1.1. Définissez la directive 'ServerName' globalement pour supprimer ce message

ensuite

sudo nano /etc/apache2/apache2.conf

ajouter à la fin :

ServerName reg.homelab

Et ce n’est pas encore la fin ! maintenant, il faut supprimer l’essai de liaison du port 80

sudo nano /etc/apache2/ports.conf

mettre là

Listen 3030
...
Listen 443

Et maintenant

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

OK ! Maintenant, naviguez vers :3080

Étape 2 - Convertir ce site en proxy inverse non sécurisé :) vers Gitea

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

mettre là

<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>

Faire un test de configuration

sudo apache2ctl configtest

Ajouter quelques modules Apache et redémarrer Apache

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

OK, maintenant naviguez vers ou faites un curl

# Oui, c'est toujours un http, mais sur le port 443
curl http://localhost:443
http://<Adresse_IP_du_Serveur>:443/

Étape 3 - Autorité de certification racine auto-signée et certificat du site

SweetHome-RootCA.

CANAME=MostImportant-RootCA

# optionnel, créer un répertoire
mkdir $CANAME
cd $CANAME

# générer une clé privée chiffrée en AES
openssl genrsa -aes256 -out $CANAME.key 4096

# créer un certificat, 1826 jours = 5 ans
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'

# créer un certificat pour le service
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'

# créer un fichier v3 ext pour les propriétés SAN
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
Sur les machines se connectant à gitea / registre

Enregistrer le certificat racine sur Linux :

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

Enregistrer le certificat racine sur Windows :

  • Double-cliquez sur le fichier MostImportant-RootCA.crt
  • Importez-le dans l’utilisateur local
  • Sélectionnez Autorité de certification racine approuvée.
  • Lorsque vous êtes invité à importer un certificat non approuvé – cliquez sur oui

Lorsque git pull sur Windows indique

Impossible de résoudre "unable to get local issuer certificate...

vous pouvez indiquer à git d’utiliser la couche réseau Windows en exécutant

git config --global http.sslbackend schannel

Étape 4 - Sécuriser le proxy avec un certificat auto-signé

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

Créer un certificat auto-signé SI vous ne l’avez pas fait à l’étape 3

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

Ou simplement le prendre de l’étape précédente

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

Encore une fois, ouvrez la configuration du serveur virtuel

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

Ajoutez en bas la section SSL avec les certificats

<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>

Vérifier la configuration, redémarrer le serveur, vérifier l’état et naviguer vers notre Gitea via SSL

sudo apache2ctl configtest
sudo systemctl restart apache2
sudo systemctl status apache2

# aller à : http://<Adresse_IP_du_Serveur>:443/
# ou
curl -k -v https://localhost

le navigateur affichera une alerte concernant le certificat auto-signé

Votre connexion n'est pas privée
Des attaquants pourraient essayer de voler vos informations sur reg.homelab (par exemple, les mots de passe, les messages ou les cartes de crédit). En savoir plus
NET::ERR_CERT_AUTHORITY_INVALID

Mais nous l’ignorerons pour l’instant, jusqu’à ce que nous utilisions Let’s Encrypt.

Maintenant le test Kubernetes

Faire quelques DNS…

Sur chaque nœud Kubernetes :

sudo nano /etc/hosts

et ajouter là

192.168.18.200 gitea.homelab
192.168.18.200 reg.homelab

Autorité de certification racine

Sur chaque nœud Kubernetes :

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

Et redémarrer maintenant

Créer un secret avec les identifiants du registre

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

ou

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

Nouvelle image Docker et déploiement Kubernetes

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

Maintenant nano alp2.yaml, le fichier est [disponible]disponible

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

Voici ce fichier disponible pour téléchargement : Ensuite, création de ce déploiement

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

Nettoyage

kubectl delete -f alp2.yaml

Liens utiles