[décision] État Terraform distant et authentification sans service principal

gabriel commented

2026-09-02 09:04:24 +00:00

Member

Contexte

Le tfstate doit vivre ailleurs que sur le poste. L'abonnement école ne donne pas accès à Entra ID et interdit la création d'un service principal, ce qui force un apply manuel. Il faut tracer ce choix et sa mesure compensatoire.

Sert EC01 (dossier d'architecture de Gabriel) et EC02 (revue de conception).

Options envisagées

État local, versionné dans le dépôt : rejeté, secret potentiel et pas de verrou de concurrence.
Backend Azure Blob, authentification az login utilisateur : retenu.
Backend tiers (Terraform Cloud) : rejeté, dépendance externe et compte à créer.

Sur quoi on tranche

Confidentialité de l'état, verrou de concurrence, absence de dépendance de fonctionnement, faisabilité dans les droits disponibles.

Décision retenue

À remplir à la fermeture. Sens attendu : backend azurerm sur le conteneur créé en #67, apply manuel lancé par Gabriel, preuve plan puis apply collée en MR, relecture obligatoire sur les chemins d'infra.

Alternative écartée, et pourquoi

L'apply automatique en CI, faute de service principal. Compensé par la trace en MR et la relecture. À rouvrir si un service principal devient disponible.

Fiche ADR produite

docs/adr/007-terraform-etat-distant.md

Dépendances

Se rédige avec #68 (le squelette Terraform matérialise la décision).

### Contexte Le `tfstate` doit vivre ailleurs que sur le poste. L'abonnement école ne donne pas accès à Entra ID et interdit la création d'un service principal, ce qui force un `apply` manuel. Il faut tracer ce choix et sa mesure compensatoire. Sert EC01 (dossier d'architecture de Gabriel) et EC02 (revue de conception). ### Options envisagées 1. État local, versionné dans le dépôt : rejeté, secret potentiel et pas de verrou de concurrence. 2. Backend Azure Blob, authentification `az login` utilisateur : retenu. 3. Backend tiers (Terraform Cloud) : rejeté, dépendance externe et compte à créer. ### Sur quoi on tranche Confidentialité de l'état, verrou de concurrence, absence de dépendance de fonctionnement, faisabilité dans les droits disponibles. ### Décision retenue À remplir à la fermeture. Sens attendu : backend `azurerm` sur le conteneur créé en #67, `apply` manuel lancé par Gabriel, preuve `plan` puis `apply` collée en MR, relecture obligatoire sur les chemins d'infra. ### Alternative écartée, et pourquoi L'`apply` automatique en CI, faute de service principal. Compensé par la trace en MR et la relecture. À rouvrir si un service principal devient disponible. ### Fiche ADR produite `docs/adr/007-terraform-etat-distant.md` ### Dépendances Se rédige avec #68 (le squelette Terraform matérialise la décision).

gabriel self-assigned this

2026-09-02 09:04:24 +00:00

gabriel added the

labels

2026-09-02 09:04:24 +00:00

florian added this to the EnerVision project

2026-09-02 14:51:27 +00:00

gabriel was unassigned by florian

2026-09-03 08:04:37 +00:00

florian self-assigned this

2026-09-03 08:04:37 +00:00

florian commented

2026-09-03 08:46:21 +00:00

Member

Décision retenue

L'état vit dans le conteneur tfstate du compte de stockage créé par #67, sous la clé enervision/terraform.tfstate, via le backend azurerm. Le conteneur est créé hors Terraform, versioning actif.

L'authentification est celle de l'utilisateur, par az login, sur le tenant 7f4f3591-… verrouillé dans providers.tf. Aucun service principal n'est créé, aucun secret Azure n'entre dans le magasin de Forgejo — backend.tf ne porte que des noms de compte, de conteneur et de clé, qui ne sont pas des secrets et passent le scan de fuite.

L'apply est manuel, lancé par Gabriel. Toute MR touchant infra/terraform/ porte en commentaire la sortie de terraform plan -out avant la fusion, puis celle du terraform apply du plan enregistré après. Relecture par un pair obligatoire sur ces chemins.

Ce qui a fait pencher

L'état porte en clair les valeurs que le fournisseur lui rend, donc ENF-12 exclut de le versionner : la question n'était pas de savoir si un backend distant valait le détour, mais lequel. azurerm pose un bail sur le blob pendant l'opération — c'est la seule des trois options qui donne le verrou de concurrence sans compte externe — et le versioning du conteneur fournit le retour arrière, là où un état perdu se reconstruirait sinon ressource par ressource au terraform import. Terraform Cloud a été écarté pour la dépendance de fonctionnement : un compte hors abonnement, sur un service que le jury ne peut pas inspecter, pour une empreinte cloud limitée à trois ressources (#43).

Alternative écartée

L'apply automatique en CI, qui serait la façon normale de tenir ENF-09. Écarté faute de service principal : l'abonnement école ne donne pas accès à Entra ID, la chaîne n'a donc aucune identité pour parler à Azure. Le choix n'était pas entre manuel et automatique, il était entre manuel et rien.

Mesure compensatoire : la trace plan puis apply en MR, et la relecture obligatoire. Ce n'est pas équivalent — cela ne garantit pas que le geste a été fait, seulement qu'il est écrit et qu'un tiers l'a lu. À rouvrir si un service principal devient disponible.

Fiche ADR produite

docs/adr/0007-terraform-etat-distant.md — numérotée sur la série du groupe à quatre chiffres, comme le demande docs/adr/README.md, et non 007- comme annoncé plus haut dans ce ticket. Index des ADR mis à jour.

Décision retenue L'état vit dans le conteneur tfstate du compte de stockage créé par #67, sous la clé enervision/terraform.tfstate, via le backend azurerm. Le conteneur est créé hors Terraform, versioning actif. L'authentification est celle de l'utilisateur, par az login, sur le tenant 7f4f3591-… verrouillé dans providers.tf. Aucun service principal n'est créé, aucun secret Azure n'entre dans le magasin de Forgejo — backend.tf ne porte que des noms de compte, de conteneur et de clé, qui ne sont pas des secrets et passent le scan de fuite. L'apply est manuel, lancé par Gabriel. Toute MR touchant infra/terraform/ porte en commentaire la sortie de terraform plan -out avant la fusion, puis celle du terraform apply du plan enregistré après. Relecture par un pair obligatoire sur ces chemins. Ce qui a fait pencher L'état porte en clair les valeurs que le fournisseur lui rend, donc ENF-12 exclut de le versionner : la question n'était pas de savoir si un backend distant valait le détour, mais lequel. azurerm pose un bail sur le blob pendant l'opération — c'est la seule des trois options qui donne le verrou de concurrence sans compte externe — et le versioning du conteneur fournit le retour arrière, là où un état perdu se reconstruirait sinon ressource par ressource au terraform import. Terraform Cloud a été écarté pour la dépendance de fonctionnement : un compte hors abonnement, sur un service que le jury ne peut pas inspecter, pour une empreinte cloud limitée à trois ressources (#43). Alternative écartée L'apply automatique en CI, qui serait la façon normale de tenir ENF-09. Écarté faute de service principal : l'abonnement école ne donne pas accès à Entra ID, la chaîne n'a donc aucune identité pour parler à Azure. Le choix n'était pas entre manuel et automatique, il était entre manuel et rien. Mesure compensatoire : la trace plan puis apply en MR, et la relecture obligatoire. Ce n'est pas équivalent — cela ne garantit pas que le geste a été fait, seulement qu'il est écrit et qu'un tiers l'a lu. À rouvrir si un service principal devient disponible. Fiche ADR produite docs/adr/0007-terraform-etat-distant.md — numérotée sur la série du groupe à quatre chiffres, comme le demande docs/adr/README.md, et non 007- comme annoncé plus haut dans ce ticket. Index des ADR mis à jour.

florian referenced this issue from a commit

2026-09-03 08:51:06 +00:00

docs: tranche l'état Terraform distant et l'authentification sans service principal

florian referenced this issue from a pull request that will close it,

2026-09-03 08:56:10 +00:00

docs: tranche l'état Terraform distant et l'authentification sans service principal #108

florian closed this issue

2026-09-03 09:10:10 +00:00

gabriel added the due date 2026-09-04

2026-09-03 09:35:51 +00:00

gabriel removed the due date 2026-09-04

2026-09-03 09:40:36 +00:00