adam/Paillasse
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Paillasse/docs/adr/0002-mot-de-passe-pour-heat.md
Adam Belkacemi 67a754f733 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>
2026-10-08 10:14:24 +02:00

3 KiB
Raw Blame History

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.