[infra] L'attribution RBAC Azure est déclarée en Terraform, pas seulement en bash

justine commented

2026-09-09 09:44:14 +00:00

Member

Exigence couverte

ENF-09

Épreuve servie

EC04 · Cloud et sécurisation

Ce qu'on veut obtenir

L'unique attribution de rôle Azure du projet — « Storage Blob Data Contributor »
sur le compte stenervisiong2tfstate — est posée par infra/terraform/bootstrap.sh,
en az role assignment create. Elle fonctionne, mais elle n'apparaît nulle part
dans l'état Terraform : le seul moyen de savoir qui a quel droit sur le stockage
est de lire un script de trente lignes et de croire qu'il a été joué.

Le critère C25 demande des politiques d'accès configurées, et la façon dont on le
démontre partout ailleurs dans ce dépôt est la lecture d'un état ou d'un fichier
versionné. L'IAM Azure est le seul endroit où l'on demande au relecteur de faire
confiance à un effet de bord.

On veut que terraform state show rende le principal, le rôle et la portée.

Ce que ce ticket ne fait pas : retirer la création du bootstrap. L'œuf et la
poule est le même qu'au #67 — sans cette attribution, terraform init échoue en 403
sur le conteneur d'état, donc Terraform ne peut pas être ce qui la crée la première
fois. Le script reste l'amorçage ; Terraform l'adopte et devient la référence
lisible. Les deux ne doivent simplement plus pouvoir diverger sans qu'on le voie.

Critères d'acceptation

Une ressource azurerm_role_assignment est déclarée dans infra/terraform/,
portant le rôle « Storage Blob Data Contributor » sur le compte de stockage de
l'état, pour le principal de la session.
L'attribution déjà en place est importée, pas recréée : le terraform plan
qui suit l'import affiche « No changes ».
Un bash infra/terraform/bootstrap.sh joué après l'import ne fait plus diverger
les deux sources : le terraform plan -refresh-only suivant ne propose aucun
changement.
terraform state show de la ressource rend les trois valeurs qu'un relecteur
doit pouvoir vérifier : identifiant du principal, nom du rôle, portée.
bootstrap.sh dit en commentaire, à l'endroit où il crée l'attribution, qu'elle
est désormais aussi déclarée en Terraform et laquelle des deux fait foi.
Le runbook porte la manœuvre d'import et le remède à l'échec
RoleAssignmentExists.

Comment on le vérifie

cd infra/terraform
terraform plan                     # attendu : « No changes » après l'import
terraform state show azurerm_role_assignment.etat_donnees
terraform plan -refresh-only       # attendu : aucun changement, après un passage du bootstrap

# Ce que porte réellement l'abonnement, en regard de ce que l'état déclare
az role assignment list -o table --scope "$(az storage account show \
  -n stenervisiong2tfstate -g rg-FHeuze2023_cours-projet-eadl --query id -o tsv)"

Preuve à joindre à la demande de fusion : la sortie du plan avant fusion, celle de
l'apply après, comme le prescrit l'ADR 0007
et le modèle de MR. Banc statique : le contrôle fmt/validate du #72 couvrira
la forme dès qu'il existera ; ce ticket n'en dépend pas.

Manuel d'exploitation à mettre à jour

docs/runbooks/terraform-etat.md — section « Poser l'état sur un poste neuf » :
ajouter la manœuvre terraform import, et ce qu'il faut faire quand l'apply
échoue en RoleAssignmentExists (l'attribution existe, elle n'est pas dans l'état).
infra/terraform/README.md — le tableau des fichiers gagne la ressource.

Risque et retour arrière

Le risque principal est l'import raté. Sans import, l'apply tente de créer une
attribution qui existe déjà et échoue en RoleAssignmentExists — sans dégât, mais la
configuration reste bloquée tant que l'import n'est pas fait. Retour arrière :
terraform state rm azurerm_role_assignment.etat_donnees, qui retire la ressource de
l'état sans toucher à Azure — on revient exactement à la situation d'aujourd'hui.

Second risque, moins visible : un terraform destroy emporterait alors l'attribution,
et avec elle l'accès au conteneur d'état. Si le rôle le permet, poser un
prevent_destroy comme sur le conteneur d'archive ; sinon, l'écrire dans le runbook.

### Exigence couverte ENF-09 ### Épreuve servie EC04 · Cloud et sécurisation ### Ce qu'on veut obtenir L'unique attribution de rôle Azure du projet — « Storage Blob Data Contributor » sur le compte `stenervisiong2tfstate` — est posée par `infra/terraform/bootstrap.sh`, en `az role assignment create`. Elle fonctionne, mais elle **n'apparaît nulle part dans l'état Terraform** : le seul moyen de savoir qui a quel droit sur le stockage est de lire un script de trente lignes et de croire qu'il a été joué. Le critère C25 demande des politiques d'accès *configurées*, et la façon dont on le démontre partout ailleurs dans ce dépôt est la lecture d'un état ou d'un fichier versionné. L'IAM Azure est le seul endroit où l'on demande au relecteur de faire confiance à un effet de bord. On veut que `terraform state show` rende le principal, le rôle et la portée. **Ce que ce ticket ne fait pas** : retirer la création du bootstrap. L'œuf et la poule est le même qu'au #67 — sans cette attribution, `terraform init` échoue en 403 sur le conteneur d'état, donc Terraform ne peut pas être ce qui la crée la première fois. Le script reste l'amorçage ; Terraform l'adopte et devient la référence lisible. Les deux ne doivent simplement plus pouvoir diverger sans qu'on le voie. ### Critères d'acceptation - [ ] Une ressource `azurerm_role_assignment` est déclarée dans `infra/terraform/`, portant le rôle « Storage Blob Data Contributor » sur le compte de stockage de l'état, pour le principal de la session. - [ ] L'attribution déjà en place est **importée**, pas recréée : le `terraform plan` qui suit l'import affiche « No changes ». - [ ] Un `bash infra/terraform/bootstrap.sh` joué après l'import ne fait plus diverger les deux sources : le `terraform plan -refresh-only` suivant ne propose aucun changement. - [ ] `terraform state show` de la ressource rend les trois valeurs qu'un relecteur doit pouvoir vérifier : identifiant du principal, nom du rôle, portée. - [ ] `bootstrap.sh` dit en commentaire, à l'endroit où il crée l'attribution, qu'elle est désormais aussi déclarée en Terraform et laquelle des deux fait foi. - [ ] Le runbook porte la manœuvre d'import et le remède à l'échec `RoleAssignmentExists`. ### Comment on le vérifie ```bash cd infra/terraform terraform plan # attendu : « No changes » après l'import terraform state show azurerm_role_assignment.etat_donnees terraform plan -refresh-only # attendu : aucun changement, après un passage du bootstrap # Ce que porte réellement l'abonnement, en regard de ce que l'état déclare az role assignment list -o table --scope "$(az storage account show \ -n stenervisiong2tfstate -g rg-FHeuze2023_cours-projet-eadl --query id -o tsv)" ``` Preuve à joindre à la demande de fusion : la sortie du `plan` avant fusion, celle de l'`apply` après, comme le prescrit l'[ADR 0007](../adr/0007-terraform-etat-distant.md) et le modèle de MR. Banc statique : le contrôle `fmt`/`validate` du **#72** couvrira la forme dès qu'il existera ; ce ticket n'en dépend pas. ### Manuel d'exploitation à mettre à jour - `docs/runbooks/terraform-etat.md` — section « Poser l'état sur un poste neuf » : ajouter la manœuvre `terraform import`, et ce qu'il faut faire quand l'`apply` échoue en `RoleAssignmentExists` (l'attribution existe, elle n'est pas dans l'état). - `infra/terraform/README.md` — le tableau des fichiers gagne la ressource. ### Risque et retour arrière **Le risque principal est l'import raté.** Sans import, l'`apply` tente de créer une attribution qui existe déjà et échoue en `RoleAssignmentExists` — sans dégât, mais la configuration reste bloquée tant que l'import n'est pas fait. Retour arrière : `terraform state rm azurerm_role_assignment.etat_donnees`, qui retire la ressource de l'état **sans toucher à Azure** — on revient exactement à la situation d'aujourd'hui. Second risque, moins visible : un `terraform destroy` emporterait alors l'attribution, et avec elle l'accès au conteneur d'état. Si le rôle le permet, poser un `prevent_destroy` comme sur le conteneur d'archive ; sinon, l'écrire dans le runbook.

justine added this to the Post-jury milestone

2026-09-09 09:44:14 +00:00

justine added the

Kind/Infra

EC04

Kind/Cloud

labels

2026-09-09 09:44:14 +00:00

justine added this to the EnerVision project

2026-09-09 09:44:22 +00:00

justine added a new dependency

2026-09-09 09:49:46 +00:00

#238 ia : détection de dérive du modèle de prévision (#117)

justine removed a dependency

2026-09-09 09:49:51 +00:00

#238 ia : détection de dérive du modèle de prévision (#117)

justine added reference justine/237-iam-azure

2026-09-10 09:20:51 +00:00

justine was assigned by gabriel

2026-09-10 10:23:07 +00:00

justine commented

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

Author

Member

Le critère « le terraform plan qui suit l'import affiche No changes » ne
sera pas tenu, et ce n'est pas l'import qui est en cause.

L'import est fait, il est propre : azurerm_role_assignment.etat_donnees ne
propose plus rien, state show rend les trois valeurs, et un passage de
bootstrap.sh suivi de terraform plan -refresh-only ne fait diverger aucune
ressource. Les cinq autres critères sont tenus.

Ce qui reste au plan, ce sont trois lignes du #69, jamais appliquées :

azurerm_monitor_action_group.capacite will be created                                                                                                                                                                       
azurerm_monitor_metric_alert.capacite will be created                                                                                                                                                                       
azurerm_storage_management_policy.archive[0] will be created                                                                                                                                                                
Plan: 3 to add, 0 to change, 0 to destroy.

L'apply du 10/09 a échoué sur les deux premières en
403 AuthorizationFailed — Microsoft.Insights/actionGroups/write. Lecture de
la définition du rôle Devops-cours-projet-eadl faite dans la foulée : il ne
porte que Microsoft.Insights/components/* et diagnosticSettings/*. Ni
actionGroups, ni metricAlerts. Le #69 et l'amendement du 07/09 de l'ADR
0012 affirmaient Microsoft.Insights/* accordé — c'était une déduction, pas
une mesure. L'alerte de capacité n'a donc jamais été en service. La
troisième ligne, la rétention, est le refus déjà connu de l'ADR 0012.

Aucun membre du groupe ne peut débloquer ça : le rôle est le même pour tous, et
donner ses droits à quelqu'un d'autre donne aussi son blocage. Il faut qu'un
compte enseignant ajoute Microsoft.Insights/actionGroups et metricAlerts au
rôle, ou attribue « Monitoring Contributor » sur le groupe.

La MR porte donc le plan complet, avec ces trois lignes expliquées, plutôt
qu'un « No changes » qui n'existe pas. Les affirmations fausses relevées au
passage sont corrigées dans la même MR, datées et sourcées.

Le critère « le `terraform plan` qui suit l'import affiche *No changes* » ne sera pas tenu, et ce n'est pas l'import qui est en cause. L'import est fait, il est propre : `azurerm_role_assignment.etat_donnees` ne propose plus rien, `state show` rend les trois valeurs, et un passage de `bootstrap.sh` suivi de `terraform plan -refresh-only` ne fait diverger aucune ressource. Les cinq autres critères sont tenus. Ce qui reste au `plan`, ce sont **trois lignes du #69**, jamais appliquées : azurerm_monitor_action_group.capacite will be created azurerm_monitor_metric_alert.capacite will be created azurerm_storage_management_policy.archive[0] will be created Plan: 3 to add, 0 to change, 0 to destroy. L'`apply` du 10/09 a échoué sur les deux premières en `403 AuthorizationFailed — Microsoft.Insights/actionGroups/write`. Lecture de la définition du rôle `Devops-cours-projet-eadl` faite dans la foulée : il ne porte que `Microsoft.Insights/components/*` et `diagnosticSettings/*`. Ni `actionGroups`, ni `metricAlerts`. Le #69 et l'amendement du 07/09 de l'ADR 0012 affirmaient `Microsoft.Insights/*` accordé — c'était une déduction, pas une mesure. **L'alerte de capacité n'a donc jamais été en service.** La troisième ligne, la rétention, est le refus déjà connu de l'ADR 0012. Aucun membre du groupe ne peut débloquer ça : le rôle est le même pour tous, et donner ses droits à quelqu'un d'autre donne aussi son blocage. Il faut qu'un compte enseignant ajoute `Microsoft.Insights/actionGroups` et `metricAlerts` au rôle, ou attribue « Monitoring Contributor » sur le groupe. La MR porte donc le plan complet, avec ces trois lignes expliquées, plutôt qu'un « No changes » qui n'existe pas. Les affirmations fausses relevées au passage sont corrigées dans la même MR, datées et sourcées.

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

2026-09-10 11:07:20 +00:00

[237] IAM Azure #264