Technische architectuurnotities: layers en validatie van firewallregels¶

Twee ontwerpnotities die uitleggen waarom delen van het platform zo zijn gebouwd: hoe de hub-deployment is opgedeeld in layers, en hoe wijzigingen in firewallregels in een pull request worden gevalideerd. Wat de layers vandaag bevatten en in welke volgorde ze draaien, staat in Deployment layers.

Waarom de hub in layers is opgesplitst¶

De deployment is herstructureerd in layers na een layer assessment. Het principe: splits de hub in delen die elk één doel hebben, zodat de complexiteit afneemt en elk deel kan worden beheerd en gewijzigd zonder de andere aan te raken.

Het assessment beoordeelde elke layer op drie punten: zijn doel, de componenten die erbij horen en de onderbouwing om hem apart te houden. De onderbouwing kwam steeds op dezelfde redenen neer:

Reden	Betekenis
Afhankelijkheid	Sommige dingen moeten bestaan voordat andere erop kunnen worden gebouwd (management groups en policies vóór assignments, een hub vóór spokes)
Isolatie	Een wijziging in één layer mag de componenten van een andere niet raken
Snelheid	Delen die vaak veranderen (firewallregels, policies, monitoring) deployen sneller als ze een eigen, kleinere state hebben
Eigenaarschap	Componenten die bij één onderwerp horen (connectivity, management, identity) zijn makkelijker samen te beheren en te reviewen

Layer voor layer¶

Layer	Doel	Waarom apart
`foundation`	De baseline voor het platform, per regio. Regiobrede componenten waarop de andere layers voortbouwen: action groups, het DDoS protection plan, management groups (eenmaal per tenant), policy definitions en initiatives	Het is het eerste wat in een regio wordt gedeployd, en anderen gebruiken wat het aanmaakt
`connectivity`	Alles voor connectiviteit binnen Azure, tussen regio's en naar on-premises: Virtual WAN en hub, gateways, ExpressRoute, DNS resolver, Bastion, Application Gateway en WAF, Azure Firewall en zijn policy, IP-groepen, route tables, network security groups	Eén plek om alle netwerkcomponenten te configureren en te controleren
`management`	De componenten die de omgeving beheren en monitoren: Log Analytics, Azure Monitor en alerts, Automation, Storage, Key Vault, Sentinel	Monitoring- en beheercomponenten deployen snel en zijn apart makkelijker soepel draaiende te houden
`identity`	Het netwerk voor legacy identiteitsservices zoals Active Directory-domeincontrollers: een virtual network met network security groups en route tables	Identiteitscomponenten blijven geïsoleerd van wijzigingen aan andere componenten, en domeincontrollers krijgen een eigen subnet met de juiste regels
`postdeployment`	Configuratie nadat de omgeving bestaat: policy assignments en exemptions, diagnostic settings, Defender for Cloud	Makkelijker om de omgeving naar de eisen van de organisatie te configureren, en dat te herhalen zonder infrastructuur opnieuw te deployen
`firewall`	De firewall rule collection groups, rule collections en regels (network, application en NAT)	Regels veranderen vaak. Een aparte layer maakt het makkelijker ze correct toe te passen en maakt een regelwijziging veel sneller

Afhankelijkheden tussen layers bepalen de volgorde: eerst foundation, dan connectivity, dan management, identity en firewall, dan postdeployment (Deployment layers).

De code is sinds het assessment verhuisd

Het assessment noemt de private DNS-zones voor private link in de foundation layer. De huidige code maakt de zones aan in de connectivity layer en houdt alleen de private DNS policy definitions in foundation. Vertrouw op Deployment layers voor de actuele inhoud, en gebruik deze pagina voor de redenering.

Zo gebruik je dit als je een component toevoegt¶

Vraag je bij iets nieuws af waar het thuishoort:

Wat moet bestaan voordat het kan worden aangemaakt? Het hoort in een latere layer dan dat.
Verandert het vaak, of door een ander team? Geef het een eigen layer of zet het bij de layer die in hetzelfde tempo verandert.
Kan een fout erin iets onverwants beschadigen? Houd het dan uit die layer.
Heeft hetzelfde onderwerp al een layer? Zet het daar.

Zie Nieuwe functionaliteit bouwen.

Firewallregels valideren in een pull request¶

Firewallregels zijn JSON-bestanden in de configuratierepository. Een fout erin wordt pas gevonden als hub draait, en een mislukte firewall-apply kan het verkeer onderbreken (Bekende problemen). Een continuous integration (CI) pipeline op de pull request vindt de fouten vroeg, voordat er iets naar Azure wordt gedeployd, en vertelt de aanvrager wat er moet worden aangepast.

Hoe het werkt¶

De CI-pipeline is een YAML-pipeline die in de configuratierepository staat, naast de firewallregelbestanden.
Hij draait een PowerShell-script tegen de hele repository. Het script selecteert de JSON-bestanden met een padfilter, zodat het alleen naar firewallregelbestanden kijkt en naar geen andere bestanden.
Als een check faalt, meldt de pipeline een fout en kan de pull request niet worden afgerond.

Wat hij controleert¶

Check	Waarom het ertoe doet
De prioriteiten van de regels vallen binnen de limieten van Azure	Een prioriteit buiten het bereik laat de apply mislukken
De prioriteiten zijn uniek	Twee rule collections met dezelfde prioriteit conflicteren
Gerefereerde IP-groepen bestaan	Een regel die naar een ontbrekende groep verwijst laat de apply mislukken

De checks komen uit de checklist van de reviewer in Review van pull requests: de pipeline automatiseert de onderdelen die een machine beter doet dan een reviewer.

Opzetten¶

Zet het pipelinebestand in de map pipelines/ van de configuratierepository, en het PowerShell-script in de hoofd- map, waar de pipeline het verwacht.
Maak in het project een nieuwe pipeline van dat YAML-bestand. Hernoem hem zodat zijn naam Firewall Rule validator bevat.
Voeg de pipeline toe als build validation aan de branch policy van de main-branch van de configuratierepository. De standaard parameterwaarden zijn goed.

Vanaf dat moment draait elke pull request die op main mikt de validatie. Beoordeel het resultaat als onderdeel van de review (Veilig een wijziging doorvoeren).

Status

Deze validatie is ontwikkeld en getest voor één platform. De bedoeling was om de pipeline en het script onderdeel te maken van de coderepository, zodat elk platform ze krijgt. Controleer of jouw versie van de coderepository ze bevat, en let op dat de bestandslocaties hierboven dan kunnen afwijken. De eigen config tests van de coderepository draaien een vergelijkbare check aan het begin van elke hub-run (Pipelines en workflows), die dezelfde fouten later vangt, voordat Terraform start. Bekende beperkingen van de validators staan in Bekende problemen.