c1e443ea73
Testé sur le serveur réel à la demande d'Adam : une application credential --unrestricted échoue avec la même erreur Keystone que l'application credential restreinte. Confirme que seule l'authentification par mot de passe permet à Heat de créer son trust. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
75 lines
3.8 KiB
Markdown
75 lines
3.8 KiB
Markdown
# 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.
|