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

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.

Vérifié aussi (2026-10-08, à la question d'Adam) : --unrestricted ne change rien. Une application credential créée avec openstack application credential create ... --unrestricted échoue exactement pareil (heat-engine.log : même trace, même Forbidden: Delegated tokens cannot manage trusts, HTTP 403). --unrestricted lève seulement l'interdiction qu'a une application credential de créer ou supprimer d'autres application credentials et trusts en tant qu'action demandée explicitement par l'appelant — pas l'interdiction, plus profonde, qu'a Keystone de délivrer un nouveau trust à partir d'un jeton qui est lui-même issu d'une délégation. C'est cette seconde règle que Heat déclenche (il crée le trust lui-même, côté serveur, pour pouvoir agir plus tard au nom de l'appelant) : aucune option d'application credential ne la contourne.

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.