Ga naar inhoud

Spoke canvas: wat een deployment aanmaakt

Het spoke canvas is de baseline die het platform in een spoke uitrolt. Er gaat één spoke-JSON-bestand in, en er komt een subscription uit met netwerk, identiteit, toegang en een paar gedeelde bouwstenen. Deze pagina legt uit wat er wordt aangemaakt, hoe de service principal van een spoke zich gedraagt en wat de deployment-identiteit nodig heeft. Voor de instellingen van het JSON-bestand, zie de Spoke-JSON-referentie. Voor de inputs en outputs van de Terraform erachter, zie de Spoke canvas-modulereferentie.

De documentatie gebruikt spoke canvas en workload environment voor hetzelfde ding. Deze pagina gebruikt spoke canvas of spoke.

Doel

De deployment is volledig geautomatiseerd en wordt aangestuurd door één JSON-bestand per spoke. Het resultaat is een fundament, met connectiviteit, identiteit en veilige standaarden, waarop het workload team zijn eigen oplossing bouwt. Het team krijgt genoeg vrijheid om zijn eigen resources te deployen en te configureren, maar de basisresources blijven onder controle van het platformteam.

Deploymentflow

flowchart LR
    f["Spoke JSON file<br/>+ common settings"] --> p["Prepare<br/>schema + config tests"]
    p --> s["Subscription layer<br/>name, tags, management group"]
    s --> c["Spoke canvas layer<br/>plan"]
    c --> a["Approve<br/>(optional)"]
    a --> x["Apply"]
    x --> r["Spoke ready:<br/>network, groups, PIM,<br/>service principal, Key Vault, storage"]

De onderdelen komen overeen met de stappen van een spoke-run die beschreven staan in Pipelines en workflows. Twee Terraform roots doen het werk, met aparte state: de subscription layer en de spoke canvas layer (Provisioning). De subscription moet bestaan voordat het canvas wordt gedeployd; zie Subscription provisioning voor het waarom en hoe.

Wat er in Azure wordt aangemaakt

Resources zijn er om de workload basisfunctionaliteit te geven en de vrijheid om die te gebruiken. Voorbeeld: de Key Vault bevat de credentials van de spoke service principal, en het workload team kan hem ook gebruiken voor zijn eigen secrets. De eigen resources van de workload kunnen dan opnieuw worden gedeployd zonder die secrets kwijt te raken.

Resource Bedoeld gebruik Opmerkingen
Resource group (per regio) Bevat de onderstaande resources Network Watchers gebruiken een aparte, eigen resource group
Log Analytics workspace De eigen logging van het workload team, bijvoorbeeld een Application Insights-instance die eraan is gekoppeld Standaard aan
Virtual network Connectiviteit tussen de resources van de spoke, en naar resources buiten de spoke Verkeer van of naar buiten de spoke gaat via de hub firewall en heeft firewallregels nodig
Subnets Flexibel aantal per virtual network Elk subnet kan een NSG, een route table, service endpoints en delegations hebben
Network security groups Een of meer per virtual network. Eén per subnet is good practice, maar niet verplicht Een subnet zonder NSG krijgt een standaard-NSG
Route tables Voor de zeldzame gevallen die specifieke routes nodig hebben Huidige platformversies hebben geen extra routes nodig. Koppel een route table aan een subnet in het spoke-bestand
Hub connection Verbindt het virtual network met de virtual hub van de regio Standaard peerHub: true. De DNS van het virtual network wijst naar de hub-DNS-server van de regio
Key Vault Credentials van de spoke service principal, en secrets van de workload Standaard aan. RBAC-modus. Private endpoint en publieke toegang zijn configureerbaar
Storage account Voor de workload, bijvoorbeeld Terraform state Standaard aan. Versleuteld met een customer-managed key die in de Key Vault staat. Private endpoints en publieke toegang zijn configureerbaar
Network Watcher Netwerkdiagnostiek Optioneel. Eén per regio als hij is ingeschakeld
Service principal De identiteit waarmee het workload team deployt Wordt altijd aangemaakt. Zie Service principal en credentials
Azure DevOps-repository en service connection Een plek voor de workloadcode en een connectie voor de pipeline ervan Optioneel, alleen als het azdo-blok bestaat. De repository wordt alleen aangemaakt als hij nog niet bestaat
GitHub-repository en federated credentials Hetzelfde, voor GitHub Optioneel, via de GitHub-extensie
Shared services Gebruik van shared API Management, Container Registry, Service Bus of Event Hub Optioneel, via extensions

Resourcenamen, standaardwaarden en de optionele blokken staan in de Spoke-JSON-referentie en in Wat er wordt aangemaakt.

Virtual network en adresruimte

Een virtual network wordt met zijn adresruimte geconfigureerd in het spoke-bestand. Plan de grootte met ruimte om te groeien: de adresruimte van een netwerk in gebruik wijzigen is een ingrijpende wijziging. Gebruik de IP-sizingrichtlijnen.

Schakelaars voor Key Vault en storage account

Instelling Effect
resourceconfiguration.keyvault.deploy: false Geen Key Vault en geen Key Vault private endpoint. Er wordt geen secret van de service principal opgeslagen
resourceconfiguration.storageaccount.deploy: false Geen storage account en geen private endpoints voor storage
Storage account ingeschakeld De Key Vault wordt altijd gedeployd, omdat het storage account hem nodig heeft voor versleuteling met een customer-managed key
Beide op false Geen van beide wordt aangemaakt

Service principal en credentials

Voor de spoke wordt altijd een service principal aangemaakt. Het workload team gebruikt hem om resources in de subscription te deployen en te configureren. Hij is permanent lid van de Owners-groep van de spoke, dus hij heeft Owner op de subscription. Als de Key Vault en het storage account bestaan, is hij ook Key Vault Administrator op de Key Vault en Storage Blob Data Owner op het storage account.

Welke credential de service principal krijgt, hangt af van hoe de spoke is geconfigureerd:

Spoke-configuratie Credential
Azure DevOps service connection met useFederatedCredentials: true, of de GitHub-extensie ingeschakeld Geen secret. De service connection of workflow gebruikt workload identity federation (OIDC)
Azure DevOps service connection zonder useFederatedCredentials (standaard) Er wordt een secret gegenereerd. Client ID en secret worden in de Key Vault opgeslagen
Geen Azure DevOps en geen GitHub, Key Vault ingeschakeld Er wordt een secret gegenereerd en in de Key Vault opgeslagen
Geen Azure DevOps en geen GitHub, Key Vault uitgeschakeld De service principal wordt zonder credentials aangemaakt. Het workload team stelt ze buiten de spoke-deployment in

Geef de voorkeur aan federated credentials. Ze halen het secret weg, en daarmee het rotatiewerk en het verlooprisico (Secret watcher). De geldigheid van gegenereerde secrets komt uit de rotatieperiode voor secrets in de algemene spoke-instellingen; als je die waarde wijzigt, ontstaan er nieuwe secrets voor elke service principal die de spoke-deployment beheert. Wijzigingen in de required_resource_access van de service principal worden genegeerd, om onnodige updates te voorkomen (releasegeschiedenis).

Identiteit in Entra ID

Twee scopes vragen om identiteitsconfiguratie.

Scope Wat het nodig heeft
Het deploymentframework zelf Een deployment service principal die groepen, service principals en PIM-instellingen kan aanmaken, en een administrative unit om zijn bereik te beperken. Er worden geen extra groepen voor het framework aangemaakt
Elke spoke Een service principal en vier groepen

De administrative unit

De deployment kan alleen groepen beheren die in een administrative unit staan. Zo blijven de privileges van de deployment-identiteit klein: hij is Groups Administrator op die administrative unit, niet op de hele tenant. De ID van de administrative unit maakt deel uit van de algemene spoke-instellingen (SpokeCommon.tenantinfo.AdministrativeUnitId in mcp.json).

Groepen per spoke

Groep (standaardpatroon) Rol op de subscription Doel
SG_SPOKE_<wl>_<env>_Owners Owner Volledige controle over de subscription en alles erin, inclusief toegangsbeheer
SG_SPOKE_<wl>_<env>_Contributors Contributor Volledige controle over de resources, zonder de mogelijkheid om privileges in te stellen
SG_SPOKE_<wl>_<env>_Readers Reader Alleen lezen
SG_SPOKE_<wl>_<env>_Support Geen Geen eigen privileges. Bestaat zodat support-medewerkers via PIM bij de Owners-groep kunnen komen

Het voorvoegsel en het exacte patroon komen uit de naamgevingsinstellingen van het platform (Naamgeving en state). De teamgroep die in ProductTeamGroupNames staat, wordt lid van de groepen, actief of PIM-eligible afhankelijk van de modus in PIMGroupConfig (nopim, self-approve, approval). Zie Toegang, groepen en PIM en het Identiteits- en toegangsmodel.

Data plane-toegang via PIM

Reader, Contributor en Owner op de subscription geven op zichzelf geen toegang tot de data in Key Vault en storage. De spoke-deployment wijst daarom data plane-rollen toe uit een ingebouwde rolmap, op subscription-scope. Eén toewijzing dekt elke passende Key Vault of elk storage account in de subscription, of de spoke ze nu deployt of niet.

Groep Permanente toegang PIM-eligible toegang
Readers Key Vault Reader, Storage Blob Data Reader Geen
Contributors Key Vault Reader, Storage Blob Data Reader Lees- en schrijfrollen (Key Vault Secrets/Certificates/Crypto User, Storage Blob Data Contributor), zelf goedgekeurd
Owners Key Vault Reader, Storage Blob Data Reader Rollen met volledige controle (Key Vault Secrets/Certificates/Crypto Officer, Storage Blob Data Owner), met goedkeuring

De rolmap, de niveaus ervan en de PIM-profielen kunnen worden overschreven. De override is gekeyed op de exacte Azure-rolnaam:

Veld Betekenis
levels Op welke toegangsniveaus de rol wordt toegekend. levels = [] verwijdert de rol
pim_profile Welk PIM-profiel van toepassing is (bijvoorbeeld nopim, self-approve, approval)

Stel één veld in om alleen dat veld te wijzigen; een weggelaten veld behoudt zijn ingebouwde waarde. Een rol die niet ingebouwd is, moet beide velden instellen. Elke ingebouwde Azure-rol kan worden gebruikt, bijvoorbeeld voor SQL of Cosmos DB, zonder modules te wijzigen. Een override in de algemene spoke-instellingen geldt voor alle spokes, en adInfo.PIMAssignments in een spoke-bestand overschrijft die voor die spoke. Een spoke-override wint.

"adInfo": {
  "PIMAssignments": {
    "Storage Blob Data Owner": { "pim_profile": "approval" }
  }
}

Wat de deployment-identiteit nodig heeft

Een deployment service principal maakt de spokes aan. Gebruik aparte identiteiten voor de canary- en de productieomgeving van het platform, met gelijke privileges. Het opzetten ervan is onderdeel van Identiteit voorbereiden.

Scope Privilege Waarom
Azure, de landing zones management group van de platformomgeving (canary of productie) Owner Subscriptions worden eronder geplaatst. De identiteit configureert resources en RBAC in de spokes
Entra ID, administrative unit Groups Administrator De spoke-groepen aanmaken en beheren
Entra ID, Microsoft Graph application permissions Zie hieronder. Admin consent is vereist Service principals en groepen aanmaken, PIM configureren

De twee bronnen van deze lijst verschillen enigszins. Deze tabel laat zien waar ze overeenkomen en waar maar één van de twee een vermelding heeft. Controleer hem aan de hand van de documentatie van de versie die je draait.

Graph application permission In beide lijsten
Application.ReadWrite.All Ja
DelegatedPermissionGrant.ReadWrite.All Ja
Group.Read.All, GroupMember.Read.All, User.Read.All Ja
PrivilegedAccess.ReadWrite.AzureADGroup Ja
PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup Ja
RoleManagement.ReadWrite.Directory Ja
RoleManagementPolicy.ReadWrite.AzureADGroup Ja
RoleManagementPolicy.ReadWrite.Directory Slechts één lijst
AdministrativeUnit.ReadWrite.All Slechts één lijst
RoleManagement.ReadWrite.AzureADGroup, RoleManagementPolicy.Read.AzureADGroup, PrivilegedAccess.Read.AzureADGroup, PrivilegedEligibilitySchedule.Read.AzureADGroup Slechts één lijst (permissies op leesniveau)

De deployment-identiteit heeft ook een data plane-rol nodig op het storage account voor de Terraform state (Deployment layers).

Behandel deze permissies als hoge privileges

Deze Graph-permissies kunnen service principals aanmaken en PIM-policy wijzigen. Beperk de deployment-identiteit tot de pipeline die hem nodig heeft, bescherm de service connection en monitor het gebruik ervan. In het managed service-model heeft het platformteam deze identiteit in handen; in het zelfbeheermodel is dat je eigen team.