case study: the landing zone pattern

[Jean-Baptiste-Lasselle]

• Très bonnes explications quant aux notions de subscripton/tenant/management group/resource group https://www.youtube.com/watch?v=4zdEM8D9_E8&t=152s

[Jean-Baptiste-Lasselle]

[Jean-Baptiste-Lasselle]

étape zéro:

• état de départ :
  • on a une seule subscription
  • on a un seul Azure AD, par exemple que l'on utilise pour gérer tout ce qui est Microsoft 365
• step 1 :
  • Pour faire ce step 1, on doit utiliser un user azure qui est Global Admin
  • On va dans le Azure AD, dans le menu "Properties",
  • et on va cocher la case tout en bas de page, pour donner au user connecté (qui est déjà Global Admin), la permission Can manage Access to all Azure subscriptions and management groups in this tenant (en gros un tenant, = 1 Azure AD)
  • cette étape est nécessaire pour que le user Global Admin puisse réaliser les opérations de l'étape suivante, de création de subscriptions et de management groups : et ce, parce qu'au départ, quand on va créer les management groups, aucun utilisateur n'aura aucun droit sur ces management groups fraîchement créés, même pas l'utilisateur, qui a créé ces management groups, bine qu'il soit en plus Global Admin de l'Azure Active Directory. TRES IMPORTANT: Aussitôt que l'on aura terminé de créer la hiérarchie des management groups, et que l'on aura pu attribuer des permissions sur ces management groups, on retirera au user Global Admin les permissions Can manage Access to all Azure subscriptions and management groups in this tenant, en décochant la case dans le menu "Properties" du Azure AD
  • (cette étape suivante est entièrement automatisable, terraform, et là il faut du policy as code sentinel). Les management groups servent à regrouper, orgniser les subscriptions (example: un pour les subscriptions d'équipes projets, un pour les subscriptions des équipes infra core, security, networking, resilience/sre, computing, data, etc... Un autre management group pour les subscriptions qui vont prendre les factures de tout ce qui est Microsoft 365, laptop utilisateurs)

• step2 :

  • Tout les management groups créés seront dans un management group qui existe tjrs et que l'on ne peut supprimer, le "Tenant Root Group"

  • On créée les management groups et les subscriptions, en mettant les subscriptions dans les mangement groups :

  • manageemnt group "infra": toutes les souscriptions de toutes les équipes infra core

  • 80% des permissions au niveau management group :

  • on aura tjrs les owners: propriétaires, seuls eux ont le drroits d'attribuer toutes les permissions sur le même management group. 2/3 personnes maximum, ils détiennent les subscriptions contenues dans leur management group, la seule chose que je vois c'est que le modèle d'attribution des permissions doit permettre de ne pas avoir de "bottleneck". Les 2/3 personnes, tjrs au moins une dispo pour donner des droits immédiatement (donc leurs opérations standard de CRUD des permissions doivent être automatisées, afin de leur appliquer policy as code)

  • on aura toujours les contributeurs: donc eux n'auront pas le droit de donner de permissions aux autres users, mais auront des droits de leur utilisateur, sur les ressources

  • exemple typique à garder en tête :

  • pour faire du réseau par exemple, on donnera la possibilité en lecture seule sur des ressources réseaux dans d'autres subscriptions que celle de l'équipe networking. Potentiellement, pour le backbone par exemple, on voudra donner les droits en lecture seule sur toutes les ressources réseau, dans toutes les autres subscriptions

  • un owner, c'est qqun qui a tout les droits, y compris de gérer les permissions des autres users

  • un contributeur, c'est qqun qui a le droit de tout faire, sauf de gérer les permissions de qui que ce soit

  • pour tout ce qui est automatisation, on utilise des services principals (et des managed identities): eux doivent toujours être contributeurs

  • case :

  • 7 abonnements ("subscriptions"), 7 service principals

  • créer un "management group", Azure AD, appelé "Azure Reader", les users de ce groupe pourront lire dans tout les autres abonnements

  • mettre les 7 service principals dans ce groupe AD, appelé "Azure Reader"

  • chaque service principal devra avoir le droit de lecture sur tout les autres abonnements

  • sur chaque abonnement (subscription), je mets un service principal en rôle contributeur

  • règle: ne pas mettre de permissions spécifiques sur un "resource group"

  • avec ce modèle, lorsque'une équipe projet (un prestataire) demande "donnes moi tout ce dont j'ai besoin pour déployer":

    • on lui donne une subscription, avec un service principal qui a "toutes les permissions dans sa subscription (son abonnement), et permission de lecture sur les autres subscriptions_",
    • comme ça on a l'isolation entre les différentes équipes projet : on est sûr qu'ils ne pourront rien modifier "autre part que dans leur propre monde"
    • dans l'équipe projet :
    • Les devs ont seulement le droit de lecture, sur les resources
    • Le ou les devops, ont le rôle contributeur comme le service prinicpal

[Jean-Baptiste-Lasselle]

note, très important : si on créée un abonnement (une "subscription") Azure, cela ne coûte rien, un abbonnement en lui-même ne coûte strictement rien

[Jean-Baptiste-Lasselle]

n'importe quel projet qi commence sur azure, derait toujours commencer avec au moins 4 "subscriptions" (abonnements) :

• une "subscription", pour tout ce qui est identité
• une "subscription", pour tout ce qui est réseau
• une "subscription", pour tout ce qui est management (cad?)
• une "subscription", pour toute la partie applicative (cad?) : ici c'est pour déployer tout ce qu'il y a à déployer, sans toucher ce qui est fait sur le réseau,
• principe: gérer les permissions au niveau subscription, si possible à 100%,
• l'objectif de ce pattern, est de permettre et rendre aussi facile que possible, l'évolution du SI, quant l'entreprise évolue, grandit, mais aussi lorsqu'elle se réduit, il s'agit de capacité de montée/descente d'échelle
• ce pattern se veut modulaire (c'est bien le principe des "landing zones")

[Jean-Baptiste-Lasselle]

rbac

Sur les management groups, gestion permissions:

Note importante:

• Sur un Azure AD donné (un tenant, donc), on peut avoir plusieurs Abonnements
• ne faire des rôles custom (autres que les builtin) que si on a un vrai cas de blocage, pas un "supposé possible dans le futur"

Azure Policies

here i need to stress on how to integrate that with PAC (Policy As Code) tools, like sentinel

• https://github.com/hashicorp/policy-library-azure-storage-terraform
• Interesting , a few relations with PAC: make sure that the IS is CIS compliant, https://www.cisecurity.org/benchmark/azure
• https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/policy_definition
• exemple de Preventvive policy:
• exemple de feature d'une Remediation policy :
  • il y a un ensemble de resources pour lesquelles on applique cette "Remediation policy"
  • lorsqu'un problème est détecté pour des ressources, par l'audit, on peut alors créer automatiquement une managed identity, dont on se servira pour exécuter terraform , l'avantage est que la managed identity a déjà exactement toutes les permissions nécessaires pour exécuter les opérations de remédiation :

[Jean-Baptiste-Lasselle]

les tags de ressources, c'est très important, ainsi que les naming conventions, (cela fait partie de la gouvernance) :

• pour pemettre de facilement comprendre de quel app il s'agit, de quelle région azure, de quel env (prod, staging...), type de ressource (routeur ? réseau? VM ?) etc..
• tags recommandés: équipes, business unit, région azure, nom de l'app déployée sur cette infra
• très très important pour trouver les choses rapidement

il existe un outil microsoft pour gérer une normalisation de nommage :

[Jean-Baptiste-Lasselle]

Modèle prêt à l'emploi, proposé par le Cloud Adoption Framework de chez Azure

• https://github.com/azure/azure-governance-visualizer
• https://github.com/azure/azure-governance-visualizer

J'ai compris quelques choses :

• la partie management: bon cette subscription, c'est celle là qui permet de gérer les exécutions infra as code, l'automatisation terraform etc...
• la partie connectivity :
  • la chambre zéro : tout ce qui est entrée sortie vers réseau internet
  • il devrait y avoir une anti-chambre zéro: celle la permet de gérer toutes les VPN Gateway entre un réseau de l'infra, et un autre réseau qui n'est pas internet
  • il y aurait là aussi les Bastions SSH ?
  • il y a là aussi la définition de quelques réseaux communs à toute l'entreprise,
• la partie identity : là dedans il y a les DC (active directory "Domain Components")

[Jean-Baptiste-Lasselle]

Tuto spécifique cloud adoption framework / landing zones :

• https://medium.com/the-factory-nl/how-to-implement-an-azure-landing-zone-using-the-microsoft-cloud-adoption-framework-caf-part-3-461aa4dfbf6c
• https://medium.com/the-factory-nl/how-to-implement-an-azure-landing-zone-using-the-microsoft-cloud-adoption-framework-caf-part-3-461aa4dfbf6c
• et donc je vais le monter à l'envers : je parrs de l'app, de sa landing zone, que son code soit ré-uitlisable et compatible avec le cloud adoption framework

https://medium.com/the-factory-nl/how-to-implement-an-azure-landing

[Jean-Baptiste-Lasselle]

Cette vidéo sur laquelle je me suis basée est très récente, avril 2023 :

https://www.youtube.com/watch?v=4zdEM8D9_E8&t=152s

[Jean-Baptiste-Lasselle]

• https://aztfmod.github.io/documentation/
• https://github.com/Azure/caf-terraform-landingzones
• the 2 main terraform modules to implement CAF lannding zones:
• https://registry.terraform.io/modules/aztfmod/caf/azurerm/latest/examples/networking
• https://registry.terraform.io/modules/Azure/caf-enterprise-scale/azurerm/latest

[Jean-Baptiste-Lasselle]

https://github.com/aztfmod/rover

The rover is a docker container in charge of the deployment of the Azure CAF Terraform landingzones

[Jean-Baptiste-Lasselle]

https://aztfmod.github.io/documentation/docs/azure-landing-zones/landingzones/alz-intro

• aussi sur le doc terraform tuto complet CAF : https://developer.hashicorp.com/terraform/tutorials/azure/microsoft-caf-enterprise-scale

[Jean-Baptiste-Lasselle]

oh purée :

• https://github.com/onwardplatforms/azure-periodic-table-app ,(excellent celui-là pour visualiser toutes les ressources)
• https://github.com/mspnp/AzureNamingTool/wiki
• https://github.com/Azure/caf-terraform-landingzones
• the global org schema seen in video : https://aztfmod.github.io/documentation/docs/azure-landing-zones/landingzones/alz-intro
• caf comes along with already designed modules, we could repace all those modules by our own, at least bring what we don't find in their library : here i build and publish ton private terraform registry the modules, comodb, eventhub, kube, az functions, for example. That"s also for that part, tht we need to train people to work with modules, typical workflows fr each of them, most important is we need an approval process so unfra core team approves or reject modules proposed for publishing to release channel of terraform registry

[Jean-Baptiste-Lasselle]

management groups :

• identity: là il y a le seul et unique AD (unque AD, selon contexte, à discuter)
• management: ok tout ce qui est automatisation de la gestion infra, Infra As Code c'est là dedans, comprenant toutes les équipes :
  • networking
  • compute
  • data
  • security
  • sre: resilience team (auto-scalability, drp, sla, etc..)
  • automation SMEs : ceux qui sont es experts terraform, argo cd, CI/CD pipelines
  • éventuellement ici le helpdesk aussi pour les laptops, eux leurs subscription ce sera donc pour inclure toutes les conneries de serveurs de packages windows, d'automatisation installation, updates, les licenses Office 365, etc...
• connectivity :
  • cette susbcription n'est pas celle qui contient l'automatisationd e la gestion networking, pas du tout
  • cette subscription est là pour contenir tous les éléments d'infra qui établissent des connexions réseau entre des réseaux n'appartenant pas à EntrepriseExemple, et les réseaux qui appartiennent à EntrepriseExemple :
  • CHAMBRE ZERO points de connectivité réseau entre un ou plusieurs réseaux appartenant à EntrepriseExemple, et internet (WAN, Elastic IPs, serveurs de noms de domaines et configuration du type route54). Comprends :
    • les expositions sur internet, d'applications du SI
    • les bastion SSH, les APpGateway,
    • les appliances de firewall (IDS)
    • des routeurs avec redondance pour lier avec les autres réseaux privés
  • B2B 2-sided VPN Gateway points de connectivité entre un ou plusieurs réseaux appartenant à EntrepriseExemple, et un réseau appartenant à une autre entreprise
  • B2C VPN Gateway points de connectivité entre des cleints VPN et un serveur VPN pour donner accès à un salarié / un prestataire, à un ou plusieurs réseaux appartenant à EntrepriseExemple, depuis internet, a maison, etc... inclue le work from home