Ga naar inhoud

Configuratie-driftdetectie

Een spoke wordt overgedragen aan een workload team dat kan wijzigen wat er in zijn subscription staat. Die vrijheid is bewust, maar een platformteam moet kunnen zien wanneer de baseline van een spoke is afgedreven van zijn spoke-bestand. Deze pagina legt het ontwerp vast voor een gepland driftrapport per spoke, waarom het is gebouwd uit de bestaande spoke pipeline, en wat het wel en niet kan vertellen.

Besluitenlog

Dit is een ontwerpbesluit, geschreven vanuit een architecture decision record van de spoke canvas. Het is richtlijn. Controleer of de versie die je draait de drift-pipeline meelevert en hoe die in jouw configuratierepository is aangesloten.

Het probleem

Niets weerhoudt de owners van een spoke ervan om de canvas-resources te wijzigen. Contributor en Owner worden bewust gegeven, om rollen eenvoudig en het team flexibel te houden (Toegang, groepen en PIM). Ze zijn niet bedoeld om voor de canvas-resources te gebruiken, bijvoorbeeld om subnets te wijzigen.

Het platformteam wil ongewenste wijzigingen zien. De scope is beperkt tot wat Terraform binnen zijn eigen scope kan vinden.

Eisen

Eis Gevolg voor het ontwerp
Een rapport moet historisch beschikbaar zijn Sla elk rapport op met datum en tijd in de bestandsnaam
Een rapport moet beschikbaar en actueel zijn Sla het rapport ook op onder een vaste naam die altijd wordt overschreven
Rapporten moeten regelmatig worden gemaakt Een geplande pipeline, met het schema in de pipelinedefinitie

Opties

Optie Opmerking
De spoke pipeline klonen en de onderdelen hergebruiken (gekozen) Weinig te bouwen, en het blijft stabiel als de spoke-deployment verandert, omdat het grootste deel dezelfde code is
Een function app die de spoke-bestanden vergelijkt met de uitgerolde configuratie Vraagt een nieuw onderdeel en eigen logica voor wat "anders" betekent
De activity log analyseren op ongewenste wijzigingen Toont wie wat deed, maar vergelijkt niet met de beoogde staat

Besluit

Draai volgens een schema een plan voor elk spoke-bestand en rapporteer de spokes waarvoor wijzigingen te maken zijn. Een plan dat niet leeg is, betekent dat de echte configuratie afwijkt van het spoke-bestand. Het resultaat wordt als rapport naar een storage account geschreven.

Gevolgen

  • Minimale inspanning en minimaal onderhoud, omdat de pipeline de spoke-deployment hergebruikt.
  • Het inzicht is beperkt. Alleen wat in een Terraform-plan verschijnt, wordt gedetecteerd. Resources die de spoke canvas niet beheert, of instellingen die in code worden genegeerd, verschijnen niet. Zie het rapport als indicator en niet als audit.
  • Het plan kan ruis tonen die geen drift is. Zie Bekende problemen en De spoke-plannen lezen.

Hoe het werkt

flowchart LR
    t["Schedule"] --> p["Plan for every spoke file"]
    p --> d["Spokes with changes?"]
    d --> rep["Drift report (JSON)"]
    rep --> h["Timestamped file<br/>(history)"]
    rep --> l["Fixed-name file<br/>(latest)"]
    h --> st[("Storage account:<br/>dedicated container")]
    l --> st
Onderdeel Detail
Opslag Een eigen container in een storage account. Een volledig uitgerolde spoke is een goede plek: zijn storage account heeft al private endpoints en de groepen van de spoke. Geef de lezers van het rapport de rol blob reader op de container
Toegang Pipeline-agents hebben netwerktoegang nodig tot het storage account (bij voorkeur via een private endpoint), en de deployment-identiteit heeft rechten nodig om blobs te schrijven. Als je hiervoor netwerk- of policy-uitzonderingen nodig hebt, leg ze dan vast als exemptions (Governance)
Rapporten Elke run slaat hetzelfde rapport twee keer op: eenmaal met datum en tijd in de naam, voor de historie, en eenmaal onder een vaste naam die wordt overschreven, voor automatisering
Schema Een cron-expressie in de pipeline. Start de pipeline eenmalig handmatig, omdat een schema niet kan vragen om goedkeuring voor het gebruik van de agent pool

Drift in de hub

De hub heeft geen aparte drift-pipeline. Drift in de hub vind je door hub in Plan-modus te draaien: elke wijziging die je niet hebt gecommit is drift (Maandelijkse health check, Operationele verantwoordelijkheden). Een gepland driftrapport voor spokes brengt hetzelfde idee naar de spokes.

Wat je met een rapport doet

Bevinding Actie
Een wijziging die met de hand is gedaan en gewenst is Breng haar in het spoke-bestand via een pull request (Spoke wijzigen)
Een wijziging die met de hand is gedaan en niet gewenst is Draai haar terug. Een normale spoke-run herstelt de gedefinieerde staat
Een spoke-bestand dat om onduidelijke reden niet meer overeenkomt met het plan Controleer eerst de planruis in Bekende problemen