[237] IAM Azure #264
No reviewers
Labels
No labels
Compat/Breaking
EC01
EC02
EC03
EC04
EC05
EC06
Kind/BDD
Kind/Back
Kind/Bug
Kind/CICD
Kind/Cloud
Kind/Contenu
Kind/Data
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Front
Kind/IA
Kind/Infra
Kind/Monitoring
Kind/Security
Kind/Testing
Portée/Post-jury
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
ops/alerte
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
g2/enervision!264
Loading…
Reference in a new issue
No description provided.
Delete branch "justine/237-iam-azure"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Ce que ça change
L'unique droit que ce projet attribue lui-même — « Storage Blob Data
Contributor » sur le compte qui porte l'état Terraform — était posé par
bootstrap.shet invisible partout ailleurs. Il est désormais déclaré dansinfra/terraform/acces-etat.tf, adopté par import et non recréé : lescript reste l'amorçage, Terraform devient la référence lisible, et les deux ne
peuvent plus diverger sans qu'un
plan -refresh-onlyle montre.Closes #237
Preuve
$ terraform state show azurerm_role_assignment.etat_donnees
resource "azurerm_role_assignment" "etat_donnees" {
principal_id = "2ec0a07d-092b-4d60-bb04-6c5d68eeb95a"
role_definition_name = "Storage Blob Data Contributor"
scope = "/subscriptions/ca5c57dd-.../storageAccounts/stenervisiong2tfstate"
}
$ bash infra/terraform/bootstrap.sh
rôle « Storage Blob Data Contributor » déjà attribué
$ terraform plan -refresh-only
Changes to Outputs: # aucune ressource proposée — les deux sources ne divergent pas
Si ça touche
infra/terraform/terraform plan -out=tfplanci-dessous, avant la fusionterraform apply tfplan— sans objet : cette MR ne crée rien. Le seulchangement d'état est un
terraform import, dont la sortie est ci-dessous.
azurerm_monitor_action_group.capacite will be createdterraform plan -out=tfplanazurerm_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.
Aucune de ces trois lignes n'appartient à cette MR. Ce sont les ressources
du #69, non applicables :
Microsoft.Insights/actionGroups/writeetmanagementPolicies/writesont refusés au rôle école. Voir le commentaire surle #237.
azurerm_role_assignment.etat_donneesn'apparaît pas : il est importé.terraform import(le changement d'état de cette MR)$ MSYS_NO_PATHCONV=1 terraform import azurerm_role_assignment.etat_donnees
".../roleAssignments/3d7d08f1-ab14-4766-ad74-cee73868a2df"
azurerm_role_assignment.etat_donnees: Import prepared!
Import successful!
Relecture
Relecture
Ce qui suit le code
docs/runbooks/mis à jour —terraform-etat.mdporte la manœuvred'import, l'épinglage du principal, le remède
RoleAssignmentExists, leretour arrière
state rmet le piègeMSYS_NO_PATHCONVsous Git Bashdocs/adr/complété — corrections datées du 10/09 sur l'ADR 0007(
listKeysest accordé) et l'ADR 0012 (Microsoft.Insights/*nel'est pas ; l'alerte du #69 n'a jamais été en service)
Où regarder en priorité
variables.tf,principal_etat_donnees. L'état est partagé par sixmembres, une attribution de rôle désigne une personne. Sans épinglage, le
plande chacun des cinq autres proposerait de remplacer l'attribution parla sienne — donc de retirer l'accès au conteneur d'état à quelqu'un.
prevent_destroytransforme ça en erreur dure, mais l'épinglage est ce quiévite le problème. Contrepartie assumée : un object ID Entra est versionné,
alors que le dépôt refuse de versionner
email_alerte_capaciteau motifinverse. Je n'ai pas trouvé d'échappatoire propre — avis bienvenu.
Pas de bloc
importcomme dansstockage.tf. L'identifiant d'uneattribution est un GUID tiré au hasard par
bootstrap.sh, donc noncalculable depuis la config. D'où un
terraform importen ligne de commande,documenté au runbook. C'est une divergence de motif assumée.
Les corrections de documentation. Elles touchent deux ADR et le plan de
migration. Elles ne changent aucune décision, seulement les faits qui les
motivaient — mais ça mérite un second regard.
Relecture (marvin)
Verdict : bon travail, deux points a corriger avant fusion. Le coeur --- attribution declaree en Terraform et adoptee par
import--- est correct et coherent avecstockage.tf(compte + conteneur adoptes,prevent_destroy).Verifie et OK : idempotence par-personne de
bootstrap.sh(filtreaz restsurprincipalId && roleDefinitionId) ;#checkov:skiprecentre sur la ressource ; runbookterraform-etat.mdcomplet ; corrections de doc factuelles, sans impact sur les decisions. CI Terraform/Checkov verts ; job Python rouge mais herite dedevelop(#266), pas introduit ici.A corriger
GUID de principal en dur (
variables.tf) +prevent_destroy= point de defaillance unique. Si l'attribution de2ec0a07d-...disparait, leplande tout le monde bute en erreur dure. Proposerlifecycle { ignore_changes = [principal_id, principal_type] }(supprime le footgun et le besoin de committer un object ID perso), ou au minimum justifier le choix dans l'ADR 0007. Nit lie : le commentaire du bloclocalsd'acces-etat.tfparle encore d'un defautnull.docs/runbooks/stockage-secours.mdnon corrige : la PR affirme partout que l'alerte de capacite n'a jamais ete en service, mais ce runbook (SS3) la decrit toujours comme active. Deux runbooks contradictoires --- meme correction datee a apporter la, et verifier le rapport EC04 (#260).Nits :
outputs.tfimprime l'object ID a chaque plan ;terraform planportera << 2 to add >> en permanence (ok, documente) ; section << ## Relecture >> dupliquee dans le corps de la PR.