🧪 TP3 — Réseau, Key Vault et environnements dev / prod

⏱️ 90 min · 👥 Binôme — on échange les rôles ! (le reviewer d'hier devient exécutant) · 🏅 Badges : Network Weaver · Reviewer Eagle-Eye

🎯 Objectifs

Étendre le socle du TP2 : NSG + VNet (2 sous-réseaux) + Key Vault, branchés sur Log Analytics.
Piloter 2 environnements (dev, prod) avec le même code, des tfvars et des states distincts.
Construire un pipeline avec promotion : plan:dev + plan:prod → apply:dev (auto) → apply:prod (manuel).

🎭 Scénario : l'observabilité est en place. Le projet applicatif arrive et réclame un réseau, un coffre-fort à secrets… en dev et en prod, identiques à l'attribut près.

🗺️ Architecture visée (d'après le tutoriel AVM, version allégée)

flowchart TB
    subgraph RG["📦 rg-pair01-dev-app"]
        LAW["📊 Log Analytics<br/>log-pair01-dev"]
        subgraph VN["🌐 vnet-pair01-dev (10.10.0.0/22)"]
            S1["snet-…-app<br/>10.10.0.0/23"]
            S2["snet-…-data<br/>10.10.2.0/23"]
        end
        NSG["🧱 nsg-pair01-dev-app<br/>HTTPS depuis le VNet uniquement"]
        KV["🔐 kv-pair01-dev-xxxx<br/>RBAC activé"]
    end
    NSG --- S1
    VN -.->|"diagnostic settings"| LAW
    KV -.->|"diagnostic settings"| LAW

🧩 Ce qu'on omet volontairement du tutoriel AVM : NAT Gateway, Bastion, VM (coût et temps). La méthode reste identique, vous pourrez les ajouter en bonus.

📦 Sources : solutions/tp3 (à ne consulter qu'en dernier recours) · modules sur le Registry AVM

✅ Prérequis

TP2 terminé : rg-<pair_id>-dev-app et log-<pair_id>-dev existent, main à jour.
Nouvel exécutant = ancien reviewer (changez de poste/de dépôt si besoin, ou travaillez dans le dépôt de l'un des deux).

⏱️ Découpage

Phase	Durée	Qui
0 · Préparer la branche	5 min	🧑‍💻
1 · Variables et tfvars	10 min	🧑‍💻
2 · Les 3 nouveaux modules	30 min	🧑‍💻
3 · Pipeline dev/prod	15 min	🧑‍💻
4 · Revue	15 min	🕵️
5 · Merge, apply dev, promotion prod	15 min	Binôme

🛠️ Phase 0 — Préparer la branche (5 min)

bash

cd ~/lab-avm-pair01
git switch main && git pull --rebase
git switch -c feature/tp3-reseau-keyvault

Dans GitLab, ouvrez une Merge Request en Draft dès maintenant (bonne habitude : la MR est le lieu de la discussion).

🧱 Phase 1 — Variables et valeurs par environnement (10 min)

1.1 Ajouter `virtual_network_cidr` à `variables.tf`

Ajoutez avant le bloc locals :

hcl

variable "virtual_network_cidr" {
  description = "Plage CIDR du VNet (au moins un /22, ex. 10.10.0.0/22)."
  type        = string

  validation {
    condition     = can(cidrhost(var.virtual_network_cidr, 0)) && tonumber(split("/", var.virtual_network_cidr)[1]) <= 22
    error_message = "virtual_network_cidr doit être un CIDR valide d'au moins un /22."
  }
}

🛡️ La validation est un garde-fou à l'écriture : une plage invalide échoue au plan, pas en pleine nuit.

1.2 Compléter `envs/dev.tfvars` et créer `envs/prod.tfvars`

hcl

# envs/dev.tfvars
environment          = "dev"
location             = "westeurope"
virtual_network_cidr = "10.10.0.0/22"

tags = {
  owner       = "formation@contoso.example"
  costcenter  = "CC-TRAINING-001"
  application = "lab-avm"
  criticality = "low"
}

hcl

# envs/prod.tfvars
environment          = "prod"
location             = "westeurope"
virtual_network_cidr = "10.20.0.0/22"   # plage DISTINCTE de dev

tags = {
  owner       = "formation@contoso.example"
  costcenter  = "CC-TRAINING-001"
  application = "lab-avm"
  criticality = "high"
}

🧮 Mini-calcul : `cidrsubnet`

cidrsubnet("10.10.0.0/22", 1, 0) → ? et cidrsubnet("10.10.0.0/22", 1, 1) → ?

👀 Réponse

On ajoute 1 bit au préfixe : /22 → /23. Index 0 → 10.10.0.0/23 (10.10.0.0 – 10.10.1.255). Index 1 → 10.10.2.0/23 (10.10.2.0 – 10.10.3.255). Terraform calcule les sous-réseaux, plus d'erreur de calcul à la main (et de chevauchement !).

🧩 Phase 2 — Les 3 nouveaux modules (30 min)

Pour chaque module : Registry → Provision Instructions → exemples → adapter. C'est la méthode du tutoriel AVM.

Ordre de construction (dépendances)

flowchart LR
    RG["module.resource_group<br/>(TP2)"] --> LAW["module.log_analytics<br/>(TP2)"]
    RG --> NSG["module.nsg"]
    NSG --> VNET["module.vnet"]
    LAW --> VNET
    LAW --> KV["module.key_vault"]
    RG --> KV
    RND["random_string<br/>name_suffix"] --> KV
    CFG["data azapi_client_config"] --> KV

2.1 Données et suffixe aléatoire (2 min)

Ajoutez à main.tf :

hcl

data "azapi_client_config" "this" {}

# Les noms de Key Vault sont GLOBAUX dans Azure → suffixe aléatoire
resource "random_string" "name_suffix" {
  length  = 4
  special = false
  upper   = false
}

2.2 Le Network Security Group (8 min)

Module	`Azure/avm-res-network-networksecuritygroup/azurerm` — version 0.4.0
Nom	`nsg-${local.name_prefix}-app`
Règle	Autoriser HTTPS (443/TCP) depuis `VirtualNetwork` uniquement, priorité 200

🆘 Indice — attributs d'une règle

name, access, direction, priority, protocol, source_address_prefix, source_port_range, destination_address_prefix, destination_port_ranges (liste).

✅ Solution

hcl

module "nsg" {
  source  = "Azure/avm-res-network-networksecuritygroup/azurerm"
  version = "0.4.0"

  resource_group_name = module.resource_group.name
  location            = module.resource_group.resource.location
  name                = "nsg-${local.name_prefix}-app"
  tags                = local.tags

  security_rules = {
    https_from_vnet = {
      name                       = "allow-https-from-vnet"
      access                     = "Allow"
      direction                  = "Inbound"
      priority                   = 200
      protocol                   = "Tcp"
      source_address_prefix      = "VirtualNetwork"
      source_port_range          = "*"
      destination_address_prefix = "*"
      destination_port_ranges    = ["443"]
    }
  }
}

🔒 Remarque : le tutoriel AVM ouvre le SSH depuis * pour faire simple. Nous ne le faisons pas : c'est précisément la bêtise qu'on piégera au TP4.

2.3 Le Virtual Network (10 min)

Module	`Azure/avm-res-network-virtualnetwork/azurerm` — version 0.8.1
Nom	`vnet-${local.name_prefix}` · espace d'adressage `[var.virtual_network_cidr]`
Sous-réseau `app`	`snet-${local.name_prefix}-app` · 1ʳᵉ moitié du /22 · NSG associé
Sous-réseau `data`	`snet-${local.name_prefix}-data` · 2ᵉ moitié du /22
Diagnostics	vers le workspace Log Analytics

🆘 Indice — comment associer le NSG au sous-réseau ?

Dans le sous-réseau : network_security_group = { id = module.nsg.resource_id }. Tous les modules AVM exposent la sortie standard resource_id.

✅ Solution

hcl

module "vnet" {
  source  = "Azure/avm-res-network-virtualnetwork/azurerm"
  version = "0.8.1"

  resource_group_name = module.resource_group.name
  location            = module.resource_group.resource.location
  name                = "vnet-${local.name_prefix}"
  address_space       = [var.virtual_network_cidr]
  tags                = local.tags

  subnets = {
    app = {
      name                            = "snet-${local.name_prefix}-app"
      default_outbound_access_enabled = false
      address_prefixes                = [cidrsubnet(var.virtual_network_cidr, 1, 0)]
      network_security_group = {
        id = module.nsg.resource_id
      }
    }
    data = {
      name                            = "snet-${local.name_prefix}-data"
      default_outbound_access_enabled = false
      address_prefixes                = [cidrsubnet(var.virtual_network_cidr, 1, 1)]
    }
  }

  diagnostic_settings = {
    to_log_analytics = {
      name                           = "diag-${local.name_prefix}-vnet"
      workspace_resource_id          = module.log_analytics.resource_id
      log_analytics_destination_type = "Dedicated"
    }
  }
}

2.4 Le Key Vault (10 min)

Module	`Azure/avm-res-keyvault-vault/azurerm` — version 0.10.0
Nom	`kv-${local.name_prefix}-${random_string.name_suffix.result}`
`tenant_id`	`data.azapi_client_config.this.tenant_id`
RBAC	rôle Key Vault Administrator pour l'identité qui déploie (`...object_id`)
Diagnostics	vers Log Analytics
Réseau	`network_acls = null` ⚠️ lab uniquement

✅ Solution

hcl

module "key_vault" {
  source  = "Azure/avm-res-keyvault-vault/azurerm"
  version = "0.10.0"

  enable_telemetry    = true
  location            = module.resource_group.resource.location
  resource_group_name = module.resource_group.name
  name                = "kv-${local.name_prefix}-${random_string.name_suffix.result}"
  tenant_id           = data.azapi_client_config.this.tenant_id
  tags                = local.tags

  # ⚠️ LAB UNIQUEMENT : accès réseau public (le runner n'est pas dans le VNet)
  network_acls = null

  diagnostic_settings = {
    to_log_analytics = {
      name                  = "diag-${local.name_prefix}-kv"
      workspace_resource_id = module.log_analytics.resource_id
    }
  }

  role_assignments = {
    deployer_kv_admin = {
      role_definition_id_or_name = "Key Vault Administrator"
      principal_id               = data.azapi_client_config.this.object_id
    }
  }
}

2.5 Les sorties

Ajoutez à outputs.tf : virtual_network_id (→ module.vnet.resource_id) et key_vault_id (→ module.key_vault.resource_id).

2.6 Vérification locale

bash

terraform fmt -recursive && terraform init -backend=false && terraform validate

✅ Point de contrôle 2 : Success! The configuration is valid. (Le fichier .terraform.lock.hcl peut changer : committez-le.)

⚙️ Phase 3 — Le pipeline multi-environnements (15 min)

Le principe

flowchart LR
    V["fmt-validate"] --> PD["plan:dev"]
    V --> PP["plan:prod"]
    PD --> AD["apply:dev<br/>🤖 auto après merge"]
    AD --> AP["apply:prod<br/>✋ manuel"]
    PP --> AP

Élément	Choix	Pourquoi
Un code, N environnements	`envs/<env>.tfvars`	Zéro duplication, zéro dérive
Un state par environnement	`key = <pair>-<env>.tfstate`	Isolation du rayon d'explosion
Modèles cachés `.plan` / `.apply`	`extends`	DRY
Promotion	`apply:prod` `needs` `apply:dev`	On ne va en prod que si dev est passé
Prod manuelle	`when: manual`	Un humain décide

À faire dans `.gitlab-ci.yml`

Remplacer TF_ENV global par des variables: dans chaque job.
Créer les modèles .plan et .apply.
Créer 4 jobs : plan:dev, plan:prod, apply:dev, apply:prod.

✅ Solution

Voir solutions/tp3/.gitlab-ci.yml. Squelette :

yaml

.plan:
  stage: plan
  extends: .tf-init
  script:
    - terraform plan -var-file="envs/${TF_ENV}.tfvars" -out=tfplan
    - terraform show -no-color tfplan > plan.txt
  artifacts: { paths: [tfplan, plan.txt], expire_in: 1 day }

plan:dev:  { extends: .plan, variables: { TF_ENV: dev } }
plan:prod: { extends: .plan, variables: { TF_ENV: prod } }

apply:dev:
  extends: .apply
  needs: ["plan:dev"]
  variables: { TF_ENV: dev }
  rules: [{ if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH', when: on_success }]

apply:prod:
  extends: .apply
  needs: ["plan:prod", "apply:dev"]
  variables: { TF_ENV: prod }
  rules: [{ if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH', when: manual }]

Commit et push

bash

git add -A
git commit -m "feat(reseau): ajoute NSG, VNet et Key Vault; pipeline dev/prod"
git push -u origin feature/tp3-reseau-keyvault

🕵️ Phase 4 — La revue (15 min, reviewer)

Checklist réseau-sécurité (en plus de celle de la MR) :

Contrôle	À vérifier	✅/❌
Plages IP	dev (`10.10.0.0/22`) et prod (`10.20.0.0/22`) ne se chevauchent pas
NSG	Aucune règle `Allow` depuis `*` / `0.0.0.0/0` / `Internet`
Sous-réseaux	Les 2 /23 sont dans le /22 et ne se chevauchent pas (`cidrsubnet`)
Key Vault	Nom unique (suffixe), RBAC, diagnostics actifs
Public	`network_acls = null` est commenté « lab » (dette assumée, pas oubliée)
Plan dev	`Plan: … to add, 0 to change, 0 to destroy` (RG et LAW existent déjà)
Plan prod	Tout est à créer (premier déploiement prod) — cohérent ?

🔎 La question qui tue : « dans le plan dev, y a-t-il des ressources du TP2 en change ou destroy ? » → Si oui, quelque chose a changé de nom ou de paramètre : STOP.

Laissez ≥ 1 commentaire sur le diff, puis Approve.

🚀 Phase 5 — Merge, apply dev, promotion prod (15 min)

🧑‍💻 Merge la MR → pipeline sur main.
plan:dev et plan:prod s'exécutent ; apply:dev démarre automatiquement (✅).
Une fois apply:dev vert → apply:prod passe en attente (✋). Le reviewer le déclenche (principe des quatre yeux : celui qui a écrit n'est pas celui qui promeut).
Build > Pipelines → Environments : observez dev et prod avec leur historique de déploiements.

🔍 Vérifications

bash

# Les deux environnements
az group list --tag training=azure-iac \
  --query "[?starts_with(name,'rg-pair01')].{Nom:name, Env:tags.environment}" -o table

# Les sous-réseaux calculés par cidrsubnet
az network vnet subnet list -g rg-pair01-dev-app --vnet-name vnet-pair01-dev \
  --query "[].{Nom:name, CIDR:addressPrefix}" -o table

# Le NSG est bien sur le sous-réseau « app »
az network vnet subnet show -g rg-pair01-dev-app --vnet-name vnet-pair01-dev \
  -n snet-pair01-dev-app --query networkSecurityGroup.id -o tsv

# Deux states distincts dans le backend
# (nécessite le rôle « Storage Blob Data Reader » sur le compte du state ; sinon demandez au formateur)
az storage blob list --account-name "$TFSTATE_SA" -c tfstate --auth-mode login \
  --query "[?starts_with(name,'pair01')].name" -o tsv

Résultat attendu : pair01-dev.tfstate et pair01-prod.tfstate.

🧠 Débrief

Pourquoi un state par environnement plutôt qu'un seul ?
Si on change criticality dans envs/prod.tfvars, quels jobs s'exécutent, quelles ressources sont touchées ?
Comment ajouter un environnement qa ? (→ un qa.tfvars, 2 jobs, un state. Zéro copie de code.)

🧯 Dépannage rapide

Symptôme	Cause probable	Remède
`Unsupported argument` sur un module	Version de module différente du tutoriel	Lire l'onglet Inputs du Registry pour la version épinglée
`Invalid CIDR` / validation échoue	tfvars incorrect	Voir le message de `variable "virtual_network_cidr"`
`Vault name is already in use`	Nom de Key Vault global déjà pris	Le suffixe `random_string` change à chaque nouveau state ; relancer
`AuthorizationFailed … roleAssignments/write`	Le SP ne peut pas créer de role assignment	Formateur : rôle Role Based Access Control Administrator (bootstrap)
`apply:prod` n'apparaît pas	`apply:dev` en échec ou `needs` mal écrit	Vérifier l'orthographe des noms de jobs (`"apply:dev"`)
`plan:prod` veut tout recréer en dev	`TF_ENV` mal positionné	Contrôler les `variables:` du job et la clé de state

🏁 Fin du TP3

flowchart TB
    CODE["📄 1 code"] --> DEV["🟢 dev<br/>state pair01-dev"]
    CODE --> PROD["🔴 prod<br/>state pair01-prod"]
    TFD["envs/dev.tfvars"] --> DEV
    TFP["envs/prod.tfvars"] --> PROD

🏅 Badge : 🏅 Network Weaver (exécutant) · 🏅 Reviewer Eagle-Eye (reviewer).

⚠️ Gardez ces ressources : le TP4 les utilise (nettoyage en fin de journée).

➡️ Suite : TP4 — Un pipeline DevSecOps : sécurité, piège SSH et dérive