ajoute la liaison Laravel-OpenStack et le modèle Heat du lab 08

Un gabarit Heat généré depuis chaque lab.yaml, une stack par session de
lab (création à l'admission, suppression à l'expiration via des jobs
Redis et un worker systemd dédié). Passage du compte de service à une
authentification par mot de passe : Heat refuse de créer un trust à
partir d'un jeton d'application credential (voir ADR 0002).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/adr/0002-mot-de-passe-pour-heat.md

@@ -0,0 +1,62 @@
+# ADR 0002 — Authentification par mot de passe pour le compte de service, pas par application credential
+
+- **Date** : 2026-10-08
+- **Statut** : accepté
+
+## Contexte
+
+À l'étape 6, le compte de service `paillasse-service` (utilisé par le portail
+Laravel pour piloter OpenStack) avait été équipé d'une *application
+credential* plutôt que d'un mot de passe classique — plus simple à révoquer
+sans toucher au mot de passe principal du compte, portée limitée à un projet.
+Repris sans changement à l'étape 9 pour les appels Nova (console série).
+
+À l'étape 10, en ajoutant un client Heat pour créer une stack par lab, la
+création d'une stack de test a échoué avec `500 Internal Server Error`. Le
+journal de `heat-engine` (`/var/lib/docker/volumes/kolla_logs/_data/heat/`,
+rien dans `docker logs`) donnait la vraie cause :
+
+```
+keystoneauth1.exceptions.http.Forbidden: You are not authorized to perform
+the requested action: Delegated tokens cannot manage trusts.
+```
+
+## Décision
+
+**Le compte de service s'authentifie par mot de passe, pas par application
+credential.**
+
+Ce n'est pas un contournement : c'est une règle de sécurité Keystone, pas un
+bug. Heat a besoin de créer un *trust* (Keystone délègue temporairement les
+droits de l'appelant au moteur Heat, pour que celui-ci agisse en son nom
+pendant toute la vie de la stack). Keystone refuse catégoriquement qu'un
+jeton issu d'une application credential — un jeton déjà délégué une fois —
+en délègue un second : ce serait une chaîne de délégation, un risque de
+sécurité que Keystone élimine par construction, quelle que soit la
+configuration.
+
+Vérifié empiriquement avant de changer quoi que ce soit : mot de passe
+régénéré pour `paillasse-service`, fichier `clouds-test-password.yaml`
+temporaire avec `auth_type: password`, `openstack stack create --wait` →
+`CREATE_COMPLETE`. Confirmé avec Adam (choix : « mot de passe classique pour
+`paillasse-service` ») avant d'appliquer en dur.
+
+Changements :
+
+- `/etc/kolla/clouds-paillasse.yaml` : `auth_type: password` (mot de passe
+  généré une fois, stocké root:root 600 sur le serveur, jamais dans Git).
+  L'application credential `portail-syllabus` a été supprimée.
+- `KeystoneAuth` (nouveau) : un seul point d'authentification Laravel,
+  partagé par `NovaClient` (étape 9, adapté) et `HeatClient` (étape 10).
+- Un seul mécanisme d'authentification pour toutes les opérations OpenStack
+  du portail — pas un mécanisme par service OpenStack appelé.
+
+## Conséquences
+
+- Le mot de passe de `paillasse-service` est un secret plus sensible qu'une
+  application credential (pas de portée limitée à un projet par nature,
+  révocation = changement de mot de passe plutôt que suppression d'une
+  credential) : à tourner si jamais exposé, comme n'importe quel secret.
+- Toute future intégration OpenStack qui utiliserait des trusts (Octavia,
+  Magnum, autres templates Heat) doit réutiliser `KeystoneAuth`, pas
+  réintroduire une application credential.