Images, cloud-init et service de métadonnées

Une machine qu'on configure à la main après son démarrage est une machine qu'on ne saura pas recréer. Cette leçon montre comment préparer une instance au moment où elle démarre, avec une image système et un fichier de configuration, puis comment elle obtient ses identifiants sans qu'aucun secret n'ait été stocké dessus.

Ce que vous allez apprendre

Préparer une machine au démarrage avec cloud-init, sans y toucher ensuite.
Distinguer ce qui appartient à l'image de ce qui appartient au démarrage.
Comprendre le service de métadonnées, qui donne à la machine son identité.
Protéger ce service, cible d'une classe d'attaques bien connue.

L'image, et la préparation au démarrage

Une image est le disque de départ de votre machine. Trois façons de faire cohabitent, et le choix a des conséquences sur la sécurité comme sur le temps de démarrage.

Approche	Comment	Ce qu'elle coûte
Image officielle plus configuration au démarrage	cloud-init installe et configure	démarrage plus long, dépendances externes
Image préparée par vous	construite en amont, prête à l'emploi	un travail de fabrication, et un cycle de mise à jour
Image officielle plus configuration manuelle	quelqu'un se connecte et installe	à éviter : rien n'est reproductible

La troisième ligne mérite son avertissement. Une machine configurée à la main est une machine que personne ne saura recréer à l'identique, y compris celui qui l'a faite. Le jour où elle tombe, l'incident dure le temps de retrouver ce qui avait été installé.

cloud-init est le mécanisme standard, présent sur pratiquement toutes les images Linux officielles, quel que soit le fournisseur. Il lit une configuration que vous fournissez à la création et l'applique au premier démarrage.

#cloud-config
package_update: true
packages:
  - nginx
users:
  - name: appli
    groups: [sudo]
    shell: /bin/bash
    ssh_authorized_keys:
      - ssh-ed25519 AAAA... votre-cle
write_files:
  - path: /etc/nginx/conf.d/app.conf
    content: |
      server { listen 8080; root /var/www/app; }
runcmd:
  - systemctl enable --now nginx

Le service de métadonnées : ce que votre machine sait d'elle-même

Chaque machine du cloud peut interroger une adresse locale spéciale qui lui répond sur sa propre configuration, et, surtout, lui remet des identifiants temporaires. C'est le mécanisme qui rend possible l'identité attachée à la ressource décrite dans le principe API-first : la machine n'a aucun secret stocké, elle demande un jeton au moment de s'en servir.

Cette adresse est locale au serveur physique : elle n'est pas routée, elle ne répond qu'aux processus de la machine elle-même, et la réponse est propre à cette machine.

Puisque ce service remet des identifiants à qui l'interroge depuis la machine, un attaquant qui obtient le moyen de faire émettre une requête depuis votre serveur obtient ces identifiants. C'est le principe de la falsification de requête côté serveur : une application qui accepte une URL fournie par l'utilisateur et va la chercher peut être détournée pour interroger l'adresse de métadonnées et renvoyer le jeton dans sa réponse. Des compromissions majeures ont eu exactement cette cause.

Trois protections, à appliquer ensemble :

Exiger la version durcie du protocole quand le fournisseur en propose une. Elle impose d'obtenir un jeton par une requête préalable et limite le nombre de sauts réseau de la réponse, ce qui suffit à casser la plupart des détournements. Rendez-la obligatoire à la création de la machine.
Donner à la machine le rôle le plus étroit possible. Le jeton obtenu ne vaut que ce que le rôle autorise : un rôle qui ne sait lire qu'un seul seau de stockage limite les dégâts à ce seau.
Bloquer l'accès à cette adresse depuis les conteneurs qui n'en ont pas besoin, la plupart des orchestrateurs offrant le réglage.

Le contrôle est immédiat : depuis la machine, une requête vers l'adresse de métadonnées sans jeton préalable doit être refusée si la version durcie est bien imposée.

Prochaines étapes

Payer le calcul au bon prix Une image reproductible est le prérequis de la mise à l'échelle automatique.

cloud-init en détail La syntaxe, les modules disponibles et les erreurs de démarrage les plus fréquentes.

Gérer les identités et les accès Le rôle attaché à la machine décide de ce que ses identifiants temporaires permettent.

Exploiter au quotidien Remplacer plutôt que rustiner, et détecter la dérive entre le code et le réel.