Développement à distance #2 – Sécurisation et performance

Dans le chapitre précédent, nous avons démarré VSCode Server sur une instance distante.

C’est une victoire. Mais en l’état, votre installation est vulnérable, ou du moins non sécurisée de façon optimale. Le trafic circule donc en clair (HTTP) et le port 8080 est exposé à quiconque scanne notre adresse IP.

Pour transformer ce prototype en un outil de travail quotidien, il est indispensable de mettre en place un Reverse Proxy.

Son rôle est simple : intercepter les connexions sécurisées (HTTPS) sur le port standard 443 et les rediriger localement vers notre service.

1. Prérequis : verrouiller la partie réseau

Avant toute chose, il est nécessaire de demander à code-server de ne plus écouter les connexions venant de l’extérieur, mais uniquement celles venant de la machine elle-même (le proxy).

Modifiez votre fichier de configuration : nano ~/.config/code-server/config.yaml

Modifiez la ligne « bind-addr » comme suit :

bind-addr: 127.0.0.1:8080

Puis redémarrez le service.

ubuntu@vscode-server:~$ sudo systemctl restart code-server@$USER

Ceci aura pour effet d’avoir la certitude que vscode-server « écoutera » bien uniquement en local et ne pourra pas être contacté directement de l’extérieur

2. Implémenter le reverse proxy

Ici, vous avez deux choix :

• nginx constitue le choix standard depuis de nombreuses années ;
• Caddy, avec une approche plus simpliste (mais complète) et récente.

Pour ce billet de blog, nous avons sélectionné Caddy pour l’exemple et se familiariser si ce n’est pas déjà le cas !

Caddy sait nativement gérer l’implémentation du renouvellement de certificats SSL. Le tout, avec OVHcloud !

Installation (Debian/Ubuntu

Vous pourrez trouver une documentation plus complète pour d’autres systèmes, ou méthodes d’installation dans la documentation officielle : https://caddyserver.com/docs/install.

ubuntu@vscode-server:~$ sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https ubuntu@vscode-server:~$ curl -1sLf ‘https://dl.cloudsmith.io/public/caddy/stable/gpg.key’| sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg ubuntu@vscode-server:~$ curl -1sLf ‘https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt’| sudo tee /etc/apt/sources.list.d/caddy-stable.list ubuntu@vscode-server:~$ sudo apt update && sudo apt install caddy -y

Configuration : modifiez le fichier /etc/caddy/Caddyfile (videz-le et remplacez par ceci) :

Remplacez « dev.votre-domaine.fr » par votre propre nom de domaine avec le sous-domaine de votre choix pointant vers l’IP de l’instance.

• Configuration simple uniquement sur le port HTTP (80)

dev.your-domain.uk {    reverse_proxy 127.0.0.1:8080}

• Configuration recommandée sur le port HTTPS (443), en utilisant un domaine hébergé chez OVHcloud.

Pour la création des tokens API OVHcloud, vous pouvez vous référer à cette page : https://eu.api.ovh.com/createToken/.

dev.your-domain.fr {     tls {         dns ovh {             endpoint "ovh-eu"             application_key {$OVH_APPLICATION_KEY}             application_secret {$OVH_APPLICATION_SECRET}             consumer_key {$OVH_CONSUMER_KEY}         }     }     reverse_proxy 127.0.0.1:8080 }

Pour davantage de détails concernant la gestion des certificats SSL, vous pouvez consulter la documentation officielle de Caddy.
Application:

ubuntu@vscode-server:~$ sudo systemctl reload caddy

Désormais, si vous avez opté pour la configuration recommandée en HTTPS, votre environnement est protégé par un chiffrement SSL robuste.

Vous ne risquez plus de voir votre mot de passe intercepté sur un Wi-Fi public, ce qui est un pas en avant non négligeable vers notre but.

3. Réseau et pare-feu

Maintenant que le point d’accès est unique via l’URL en HTTPS configuré juste au-dessus, le reste des ports, sauf le SSH, évidemment, peut être coupé.

Implémentez maintenant les règles basiques, dans le pare-feu. Sur Ubuntu, l’outil standard est UFW (Uncomplicated Firewall).

Commencez par ouvrir les ports relatifs aux services fonctionnels.

ubuntu@vscode-server:~$ sudo ufw allow ssh ubuntu@vscode-server:~$ sudo ufw allow http ubuntu@vscode-server:~$ sudo ufw allow https

Activez le firewall :

ubuntu@vscode-server:~$ sudo ufw enable

Vérification de la prise en compte des règles.

ubuntu@vscode-server:~$ sudo ufw status Status: active To                         Action      From --                         ------      ---- 22/tcp                     ALLOW       Anywhere 80/tcp                     ALLOW       Anywhere 443                        ALLOW       Anywhere 45876                      ALLOW       Anywhere 22/tcp (v6)                ALLOW       Anywhere (v6) 80/tcp (v6)                ALLOW       Anywhere (v6) 443 (v6)                   ALLOW       Anywhere (v6) 45876 (v6)                 ALLOW       Anywhere (v6)

Vous pouvez également ajouter des règles plus strictes pour rejeter explicitement tout ce qui n’est pas autorisé en entrée et laisser la sortie globalement autorisée.

ubuntu@vscode-server:~$ sudo ufw default deny incoming ubuntu@vscode-server:~$ sudo ufw default allow outgoing

Désormais, si quelqu’un tente d’accéder à l’IP sur le port 8080, la connexion sera purement et simplement rejetée.

Seul le nom de domaine en HTTPS constitue la porte d’entrée légitime.
Ce petit serveur de développement, bien pratique, ressemble désormais davantage à une forteresse. 

Mais que se passe-t-il si vous décidez de supprimer cette instance pour en prendre une plus puissante et/ou la stopper pour une durée indéterminée, car votre projet est en pause ?

C’est ce que vous découvrirez dans la prochaine partie : comment isoler vos données et vos configurations sur un volume de stockage persistant pour rendre votre environnement totalement interchangeable, mais également comment automatiser le déploiement de cet environnement de développement !

L’objectif final : qu’une simple commande terraform apply suffise à faire surgir un environnement de développement, prêt à l’emploi en moins de deux minutes.