# 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.