J’ai loupé ma Landing Zone … ! je fais quoi maintenant 2/2 ?

thierrybtblog

Niveau : ★★★★☆

Seconde partie pour cet article dédié à l’architecture conceptuelle Azure qui mène à la Landing Zone applicative. LA première partie est à retrouver à cet endroit : https://thierrybtblog.wordpress.com/2024/01/30/jai-loupe-ma-landing-zone-je-fais-quoi-maintenant-1-2/

Ce que l’on trouve souvent dans les commentaires pré / post bascule d’un environnement non CAF à un environnement CAF, c’est que cela se fait, mais ce n’est pas (complètement) sans risque. Je partage cet avis en partie, même si cela ne s’applique pas à tous les cas. Si la gouvernance en place (Policy + RBAC) est en place mais sans une arborescence type CAF, alors oui, il y a pas mal de précautions à prendre avant de bascule.

Pourquoi ? Principalement par ce que les stratégies peuvent poser soucis lors de la bascule. En image, un peu de contexte. A gauche, ancienne version, on trouve 2 policy Deny, 1 sur Sub1, l’autre sur Sub2. Ce sont deux mêmes policy, mais le modèle sans MG (management groups) ne permettait pas de positionner cette stratégie autre part que sur les subscriptions.

La question à se poser lors de la bascule est : quel Scope d’Application ? (en gris sur le schéma). Il y a 4 flèches, 4 choix, les impacts sont très différents. C’est une même policy, imaginons qu’elle bloque l’utilisation d’un certain type de machines virtuelles. Je peux donc :

  • La positionner au plus haut de l’arborescence, c’est à dire sur Mon Organisation. C’est possible, mais attention, tout ce qui se trouve en dessous va « hériter » de cette stratégie. La landing Zone et (voir le schéma complet dans l’article 1), les autres MG sous Mon Organisation.
  • La positionner sur la Landing Zone. Oui, si le souhait est de couvrir un scope plus restreint et que cette policy doit également s’appliquer sur les MG Online, Corp et SAP.
  • Etc…

C’est vraiment cette partie qui peut poser soucis. C’est également vrai dans l’autre sens, c’est à dire si l’on prépare sa cible de MG conformément au CAF, avec un ensemble de policy (conformes également au CAF, voir ce sujet : https://thierrybtblog.wordpress.com/2023/12/05/azure-landing-zone-architecture-conceptuelle-et-terraform-iac-accord-parfait-2-2/).

Lors de l’attachement d’une subscription à son nouveau management groups, il peut y avoir des policy qui n’étaient pas sur la source et qui vont se retrouver sur la cible. Dernière précaution, une subscription se trouve au bout d’une arborescence, il faut donc bien prendre en compte le fait que tout ce qui est positionné sur les MG va redescendre par héritage sur la subscription en question.

Et ce sujet est le même pour les RBAC ou l’on comprend facilement que le positionnement de RBAC sur les MG va obliger à se poser les mêmes questions. Afin de ne pas donner trop ou trop peu de droits.

Alors quelle solution pour limiter et éviter les effets de bords ? Et bien la meilleur est de bien préparer sa bascule et d’adopter une méthode, la méthode Brownfield (https://learn.microsoft.com/fr-fr/azure/cloud-adoption-framework/ready/landing-zone/brownfield-considerations/?WT.mc_id=AZ-MVP-5003759).

Appelé également une transition par duplication. Comme le montre ce schéma Microsoft.

Ici, à gauche, une arborescence qui ne respecte pas le CAF, même si elle utilise déjà quelques MG. A droite, la cible, avec un passage par la méthode Brownfield

L’astuce consiste à dupliquer puis à auditer. Ce que l’on trouve dans le carré gris comme commentaire, c’est l’information suivante : Policy in « Audit Only » mode. Voilà le secret de la méthode. Simuler les effets avant bascule.

Audit Only ?

C’est cette partie qu’il faut expliquer. Les effets de policy sont fixés dans le code Json de la policy, et cela ressemble à ça :

      "effect": {
        "type": "String",
        "metadata": {
          "displayName": "Effect",
          "description": "Enable or disable the execution of the policy"
        },
        "allowedValues": [
          "DenyAction",
          "Disabled"
        ],
        "defaultValue": "DenyAction"
      }

Voir ici pour un peu plus d’explications. https://thierrybtblog.wordpress.com/2021/10/20/conformite-et-gouvernance-avec-azure-policy-1-3/).

Je n’ai pas sélectionné cette policy par hasard. Ici, les 2 effets possibles sont DenyAction et Disable. Pas Audit !
Alors comment ne pas tout casser ? En adoptant la méthode des garde-fous pilotés par les stratégies (image Microsoft).

Et donc en DESACTIVANT les effets de policy même s’ils sont de type Deny ou Modify lors de l’attachement de la policy. Première étape à gauche sur le schéma.

Cela se fait directement depuis le portail en désactivant l’enforcement ce qui équivaut à désactiver l’effet et à « basculer » cette policy en mode audit. Sans avoir à modifier le Json de la policy (bien heureusement, car cela prendrait du temps). Voilà ce à quoi correspond un garde fous de policy.

Cela est également possible As Code, ici version ARM…

{
  "type": "Microsoft.Authorization/policyAssignments",
  "apiVersion": "2019-09-01",
  "name": "PolicyAssignmentName",
  "location": "[deployment().location]",
  "properties": {
   "description": "PolicyAssignmentDescription",
   "policyDefinitionId": "[parameters('policyDefinitionId')]",
   "enforcementMode": "DoNotEnforce"
  }
}

… ou Terraform avec le paramètre enforce (https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/resource_group_policy_assignment).

Puis, comme il est expliqué dans le schéma garde-fous, la migration se fera petit à petit, sur des policy spécifiques et sur un scope réduit.

C’est donc une bascule contrôlée, par étapes, loin d’une méthode big-bang qui elle présente effectivement des risques importants.

Que faut-il retenir de cette série de 2 articles ? Qu’il existe 2 méthodes principales de migration et qu’à mon avis (mais cela peut se discuter), chacune d’elle couvre un besoin différent.

Sans Brownfield, c’est un bon choix si :

  • Mon arboresence de MG est faible ou inexistante
  • Je n’utilise pas les policy

Avec Brownfield, c’est un bon choix si :

  • Mon arboresence de MG est complexe maus NON alignée sur le CAF
  • J’utilise déjà les policy pour gouverner mon Azure

Si ce sujet vous inspire et que vous avez des remarques, ajouts, points contraires, n’hésitez pas à venir en discuter en commentaire.

Laisser un commentaire