Mise en place du nouveau serveur

Après avoir choisi Proxmox comme système cible il fallait commencer quelque part. Pour cela il faut commencer par connaître les limitations de son hébergement.

La première – et principale – limitation de l’hébergement Proxmox sur un Kimsufi chez OVH vient de l’adressage IP. Si logiquement la machine ne dispose que d’une seule adresse IPv4 elle n’est malheureusement fournie qu’avec une seule adresse IPv6 (en /128) alors qu’à partir des So-You-Start on dispose d’un /64 permettant plus de flexibilité. Il fallait donc mettre en place un réseau privé et utiliser du NAT pour rediriger le trafic depuis le noeud vers les containers / VM. Malheureusement le web-gui de Proxmox ne permet pas de faire en place du NAT facilement (du moins en v8). Il faut donc modifier le fichier /etc/network/interfaces (cf. https://pve.proxmox.com/wiki/Network_Configuration)

Au final l’architecture globale ressemble à ça :

Du fait que le réseau privé soit NATé cela veut aussi dire que les communications entre containers doivent passer par leurs IP internes. L’absence de /64 côté Kimsufi va aussi compliquer l’accessibilité des containers en IPv6.

On notera la présence d’un lien sécurisé (via OpenVPN) entre le serveur et mon domicile. Le but est d’exposer en NFS une partie de mon NAS afin de conserver les sauvegardes hors site, au cas où (et puis c’est pas comme si les datacenters ne prenaient jamais feu !)

Sécurisation de l’instance Proxmox VE

Comme tout serveur exposé sur Internet, il est bon de se demander comment améliorer la sécurité de son instance Proxmox VE. Heureusement il existe de nombreuses ressources sur Internet pour nous y aider. Je vous recommande notamment la lecture de cette documentation d’Atraxa qui liste de nombreux points. De mon côté j’ai :

• ajouté un compte utilisateur et interdit le root login en SSH
• modifié l’interface d’écoute de pveproxy pour ne plus exposer l’interface d’administration de proxmox directement sur Internet
• paramétré le 2FA sur tous les comptes utilisateurs
• activé fail2ban

Il me reste à activer le firewall mais je dois encore faire quelques tests pour ne pas me couper totalement l’accès au serveur !

Par où commencer ?

Quand on fait la migration depuis un ancien serveur vers une nouvelle architecture on peut se poser la question de par où commencer ? J’ai voulu y aller progressivement et donc commencer par migrer les différents sites web hébergés sur l’ancien serveur (dont ce blog). Je savais également que j’allais avoir besoin d’un reverse proxy et que j’allais vouloir dockeriser au maximum mes applications et services.

Docker pour garder de la flexibilité et éviter de multiplier les containers proxmox. En effet je souhaite avoir un container proxmox pour un besoin spécifique. Donc si je désire héberger 3 sites web soit je fais 3 containers proxmox, soit sur l’un d’entre eux je mets 3 containers docker. Je n’exclue pas d’utiliser des containers proxmox pour des besoins spécifiques même si une alternative docker existe. C’est d’ailleurs le cas dans l’infrastructure présentée au dessus : j’ai un container pour la base de données MariaDB et un pour Nextcloud !

Le but du reverse proxy est de mettre tout ça en musique. Côté DNS tout ce petit monde va « taper » sur la même adresse IP et c’est le reverse proxy qui va avoir la lourde tâche de répartir le trafic entre containers dockers/proxmox et le monde sauvage d’internet. Jusqu’à présent j’utilisais tout bêtement le serveur Apache de mon ubuntu. L’avantage était qu’à côté du site principal je pouvais facilement ajouter des services supplémentaires. L’inconvénient était de devoir manipuler la configuration à la main régulièrement. Heureusement des alternatives plus modernes et dédiées exclusivement au reverse proxy existent et j’ai donc décidé d’utiliser Traefik. Il a l’avantage de s’incorporer facilement avec Docker et de gérer tout seul les demandes de certificats !

Première étape : création d’un container LXC proxmox. Je pars sur une debian 12 standard et j’installe docker basiquement via apt. Tout se déroule bien. L’installation de Traefik ne pose pas de problème particulier et est bien documentée sur Internet.

A noter tout de même quelques subtilités ! Du fait que mes containers LXC soient dans un réseau privé, par défaut ils ne sont pas visibles d’internet (et c’est mieux ainsi). Par contre lorsqu’on va vouloir créer des certificats SSL il faut pouvoir prouver l’authenticité de la demande. Dans ce cas le plus simple est de passer par un resolver DNS. Du côté de Gandi c’est parfaitement géré tant par Traefik que par les outils proxmox (on verra plus tard qu’il y a tout de même des subtilités).

Au final je me retrouve avec une configuration Traefik plutôt standard :

secrets:
  gandi_api_key:
    file: "./secrets/gandi_api_key.secret"

services:
  traefik:
    image: "traefik:v2.11"
    container_name: "traefik"
    ports:
      - "80:80"
      - "443:443"
    secrets:
      - "gandi_api_key"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "/srv/traefik/acme.json:/acme.json"
      - "/srv/traefik/traefik.yaml:/etc/traefik/traefik.yaml"
      - "/srv/traefik/services:/etc/traefik/services"
    environment:
      - "GANDIV5_PERSONAL_ACCESS_TOKEN_FILE=/run/secrets/gandi_api_key"
    restart: always
    labels:
      - "traefik.enable=true"
      - "traefik.http.middlewares.auth.basicauth.users=zeguigui:$$passwordhash$$"
      - "traefik.http.routers.traefikapi.entrypoints=websecure,web"
      - "traefik.http.routers.traefikapi.middlewares=auth"
      - "traefik.http.routers.traefikapi.rule=Host(`traefik.zeguigui.com`)"
      - "traefik.http.routers.traefikapi.service=api@internal"
      - "traefik.http.routers.traefikapi.tls=true"
      - "traefik.http.routers.traefikapi.tls.certresolver=zeguigui"
      - "traefik.http.routers.traefikapi.tls.domains[0].main=*.zeguigui.com"
    networks:
      - proxy

networks:
  proxy:
    name: "proxy"

On instancie un traefik dans sa dernière version (la v3 n’est pas disponible au moment où je rédige ce billet), on ouvre les ports http et https et on configure la résolution de certificats. J’expose aussi le dashboard Traefik afin de contrôler ce qui se passe mais je protège par un mot de passe. Côté volumes :

• la permière ligne donne l’accès à Docker pour l’auto-discovery des services
• le deuxième volume sert à mémoriser les certificats lets encrypt
• le troisième permet d’ajouter un fichier de configuration (entry points, providers docker et file, le certificatesResolver, etc.)
• le dernier indique un répertoire qui sera utilisé comme source « fichiers »

Une fois que tout ceci est en place on peut commencer à jouer avec Traefik et des services sous Docker !

Mais tout ceci fera l’objet du prochain billet !