Neue Abonnements müssen einheitlich sein? Konfiguriere Subscription Vending

Veröffentlicht am:
#governance

Das manuelle Erstellen von Abonnements kann zu uneinheitlichen Namen, Verantwortlichen, Budgets, Tags und Verwaltungsgruppenzuordnungen führen. Ein neues TEST- oder PROD-Abonnement startet dadurch möglicherweise ohne die bereits für DEV verwendete Governance.

Subscription Vending ist ein automatisierter Anforderungs- und Bereitstellungsprozess. Ein Anwendungsteam fordert ein Abonnement an, eine autorisierte Person genehmigt es, und die Automatisierung erstellt und konfiguriert es einheitlich.

Im Azure-Portal gibt es keine Seite Configure subscription vending. Dieser Trip definiert einen kleinen Git-basierten Vending-Workflow und verwendet das Subscription-Vending-Modul der Azure Verified Modules (AVM) für die Bereitstellung.

Der Workflow lautet:

Subscription request
→ Review and approval
→ Deployment pipeline
→ Create and configure subscription
→ Place it under Online
→ Hand it to the application team

Verstehen, was erstellt werden muss

Subscription Vending wird nicht durch das Erstellen einer einzelnen YAML-Datei aktiviert. Erstelle für diesen Trip drei miteinander verbundene Teile in einem GitHub-Repository:

  1. Produktliniendatei — definiert zulässige Abonnementnamen, Umgebungen, die Zielverwaltungsgruppe, Tags und die Budgetpflicht.
  2. Anforderungsdatei — fordert ein einzelnes Abonnement wie CloudTrips TEST an.
  3. Automatisierung — eine Bicep-Vorlage und ein GitHub-Actions-Workflow lesen die genehmigte Anforderung und rufen Azure auf, um das Abonnement zu erstellen und zu konfigurieren.

Die YAML-Dateien enthalten nur Daten. Sie ändern nichts in Azure, bis der Workflow sie validiert und ihre Werte an das Bicep-Subscription-Vending-Modul übergibt.

Wähle in GitHub New repository und konfiguriere:

Repository name: cloudtrips-subscription-vending
Visibility: Private
Add a README file: Selected

Wähle Create repository. Verwende im neuen Repository Add file > Create new file, um die unten gezeigten Dateien anzulegen. GitHub erstellt jeden Ordner, sobald der Ordnername Teil des Dateipfads ist.

Verwende diese anfängliche Struktur:

cloudtrips-subscription-vending/
├── product-lines/
│   └── cloudtrips-online.yaml
├── requests/
│   └── cloudtrips-test.yaml
├── infra/
│   └── main.bicep
└── .github/
    └── workflows/
        └── vend-subscription.yml

Die folgenden Abschnitte füllen diese Dateien. Das Erstellen des Repositorys und der Anforderungsdateien ist sicher; die Bereitstellung benötigt die nachfolgend aufgeführten Abrechnungsberechtigungen. Führe den Deployment-Workflow erst zusammen, nachdem diese Berechtigungen bestätigt wurden.

Voraussetzungen prüfen

CloudTrips verwendet ein Microsoft Customer Agreement (MCA). Bestätige vor dem Erstellen der Automatisierung:

  • MCA-Abrechnungskonto, Abrechnungsprofil und Rechnungsabschnitt sind sichtbar
  • die Bereitstellungsidentität besitzt die erforderlichen Abrechnungs- und Tenant-Berechtigungen
  • die Verwaltungsgruppe mg-cloudtrips-online ist vorhanden
  • das Plattformteam besitzt ein GitHub- oder Azure-DevOps-Repository für den Vending-Code
  • eine autorisierte Person ist für die Genehmigung verantwortlich

Für MCA ist Azure subscription creator im Zielrechnungsabschnitt die Rolle mit den geringsten erforderlichen Abrechnungsrechten. Vergib nicht Billing account owner, nur damit das Lab funktioniert.

Öffne Cost Management + Billing, wähle das CloudTrips-Abrechnungskonto und öffne anschließend Abrechnungsprofil und Rechnungsabschnitt. Notiere unter Settings > Properties die Kennungen von Abrechnungskonto, Abrechnungsprofil und Rechnungsabschnitt. Der an Bicep übergebene Abrechnungsbereich besitzt dieses vollständige Format:

/providers/Microsoft.Billing/billingAccounts/<billing-account-id>/billingProfiles/<billing-profile-id>/invoiceSections/<invoice-section-id>

Beende den Vorgang hier, wenn du diesen vollständigen Rechnungsabschnittsbereich nicht ermitteln kannst oder kein MCA-Abrechnungsadministrator die erforderliche Rolle zuweisen kann. Das Repository kann den Prozess weiterhin dokumentieren, aber die Pipeline kann CloudTrips TEST nicht erstellen.

Erweitere die Hierarchie und bestätige, dass sie Folgendes zeigt:

CloudTrips
└── Landing Zones
    └── Online
        └── CloudTrips DEV

Erfasse die Hierarchie mit der erweiterten Gruppe Online und dem sichtbaren Abonnement CloudTrips DEV. Damit ist belegt, dass das genehmigte Ziel vorhanden ist, bevor der Vending-Workflow CloudTrips TEST erstellt.

Management-groups-Hierarchie mit erweitertem Online und sichtbarem CloudTrips DEV

Die GitHub-Bereitstellungsidentität erstellen

Verwende Workload Identity Federation, damit GitHub sich ohne gespeichertes Client Secret bei Azure anmeldet:

  1. Öffne in Microsoft Entra ID App registrations und wähle New registration.

  2. Gib sp-cloudtrips-sub-vending ein, behalte die Single-Tenant-Einstellung und wähle Register.

  3. Kopiere Application (client) ID und Directory (tenant) ID.

  4. Öffne Certificates & secrets > Federated credentials und wähle Add credential.

  5. Ermittle vor dem Ausfüllen des GitHub-Actions-Szenarios die numerischen GitHub-IDs. Führe in einem Terminal mit authentifizierter GitHub CLI aus:

    gh api users/YOUR-GITHUB-OWNER --jq .id
gh api repos/YOUR-GITHUB-OWNER/cloudtrips-subscription-vending --jq .id

    Ersetze YOUR-GITHUB-OWNER durch den Benutzer oder die Organisation, dem beziehungsweise der das Repository gehört. Der erste Befehl liefert die Repository owner ID, der zweite die Repository ID. Die Repository-ID existiert erst, nachdem das Repository erstellt wurde.

  6. Gib im Formular für die Verbundanmeldeinformation die numerische Owner-ID und Repository-ID ein. Wähle Environment als Entitätstyp und gib subscription-vending-production ein. Dieser Wert muss dem environment-Wert des Deployment-Jobs entsprechen.

  7. Erstelle die Anmeldeinformation. Ein Client Secret ist nicht erforderlich.

Kehre zum MCA-Bereich Invoice section > Access control (IAM) zurück. Wähle Add, wähle Azure subscription creator und weise die Rolle der Enterprise Application für sp-cloudtrips-sub-vending zu. Verwende die Objekt-ID der Enterprise Application, wenn Azure nach dem Principal fragt; dies ist nicht die Application/Client ID.

Vergib der Identität separat nur die Azure-RBAC-Berechtigung, die zum Einordnen von Abonnements unter mg-cloudtrips-online erforderlich ist. Wenn die Automatisierung RBAC-Rollen oder Budgets zuweist, benötigt sie auch die entsprechende Berechtigung im Zielbereich. Lass diese Zuweisungen von einem Abrechnungs- oder Tenant-Administrator ausführen und prüfen.

Öffne im GitHub-Repository Settings > Secrets and variables > Actions > Secrets. Füge diese Repository Secrets hinzu:

AZURE_CLIENT_ID: Application ID of sp-cloudtrips-sub-vending
AZURE_TENANT_ID: Directory ID of the CloudTrips tenant

Füge die Ressourcen-ID des Abrechnungsbereichs als Repository Secret hinzu:

AZURE_BILLING_SCOPE

Melde dich mit Azure CLI an und liste die MCA-Hierarchie auf, um den Wert zu ermitteln:

az login

az billing account list \
  --query "[?agreementType=='MicrosoftCustomerAgreement'].{name:name,displayName:displayName}" \
  --output table

az billing profile list \
  --account-name <billing-account-name> \
  --query "[].{name:name,displayName:displayName}" \
  --output table

az billing invoice section list \
  --account-name <billing-account-name> \
  --profile-name <billing-profile-name> \
  --query "[].{name:name,displayName:displayName,id:id}" \
  --output table

Ersetze die Platzhalter durch die name-Werte aus den jeweils vorherigen Befehlen. Kopiere die vollständige id aus dem Ergebnis für den Rechnungsabschnitt. Sie muss folgendermaßen enden:

/billingProfiles/<billing-profile-name>/invoiceSections/<invoice-section-name>

Öffne in GitHub Settings > Secrets and variables > Actions > Secrets, wähle New repository secret, verwende AZURE_BILLING_SCOPE als Namen, füge die vollständige Rechnungsabschnitts-id als Wert ein und wähle Add secret.

Der Abrechnungsbereich ist eine geschützte Konfiguration. Speichere niemals Azure-Anmeldeinformationen oder Abrechnungskennungen in einem öffentlichen Repository.

Die CloudTrips-Produktlinie definieren

Eine Produktlinie ist der Regelsatz, den jede Anforderung einhalten muss. Erstelle im Vending-Repository:

product-lines/cloudtrips-online.yaml

Füge diese Konfiguration hinzu:

productLine: CloudTrips Online
managementGroupId: mg-cloudtrips-online
namingPattern: CloudTrips <ENVIRONMENT>
allowedEnvironments:
  - DEV
  - TEST
  - PROD
defaultOwner: DmytroKlymenko@cloudtrips.onmicrosoft.com
requiredTags:
  - Application
  - Environment
  - Owner
budgetRequired: true
networkDeployment: Per environment subscription

DEV, TEST und PROD bleiben getrennte Application-Landing-Zone-Abonnements. Der Vending-Prozess gibt ihnen dieselbe Grundlage; er legt ihre Ressourcen oder virtuellen Netzwerke nicht in einem gemeinsamen Abonnement ab.

Wähle Commit changes, committe direkt nach main und verwende eine Nachricht wie Define CloudTrips Online product line. Später vergleicht der Workflow jede Anforderung mit diesen Regeln, bevor eine Bereitstellung zulässig ist.

Eine Subscription-Anforderung erstellen

Speichere für jedes Abonnement eine eigene geprüfte Anforderungsdatei. Erstelle für die nächste Umgebung eine Anforderung wie diese:

requestId: cloudtrips-test
displayName: CloudTrips TEST
environment: TEST
workload: DevTest
managementGroupId: mg-cloudtrips-online
owner: DmytroKlymenko@cloudtrips.onmicrosoft.com
budgetAmount: 100
budgetCurrency: EUR
tags:
  Application: CloudTrips
  Environment: TEST
  Owner: DmytroKlymenko@cloudtrips.onmicrosoft.com

Erstelle einen Branch namens request/cloudtrips-test. Speichere die Datei als requests/cloudtrips-test.yaml, committe sie in diesen Branch und wähle Compare & pull request. Verwende den Titel Vend CloudTrips TEST.

Die Anforderung ist eine Eingabe für den Workflow und keine Azure-Bereitstellungsvorlage. Speichere Abrechnungsbereich und Anmeldeinformationen in der geschützten GitHub-Konfiguration, nicht als Geheimnisse in der Anforderungsdatei.

Die Pipeline sollte Anforderungen ablehnen, wenn ein Pflichtfeld fehlt, die Umgebung nicht zulässig ist, der Name nicht dem Muster entspricht oder die Verwaltungsgruppen-ID von der genehmigten Produktlinie abweicht.

Verwende DevTest nur, wenn der MCA-Rechnungsabschnitt Microsoft Azure Plan for DevTest anbietet. Verwende andernfalls workload: Production; dieses Feld wählt den Azure-Plan aus und ändert nicht den Umgebungsnamen TEST.

Pull Request mit der geprüften Subscription-Anforderung für CloudTrips TEST

Die Bereitstellungsautomatisierung verbinden

Der Plattformengineer muss jetzt infra/main.bicep und .github/workflows/vend-subscription.yml implementieren. Die Bicep-Datei ruft das unterstützte Azure-Modul auf. Der Workflow authentifiziert sich bei Azure, liest die genehmigte Anforderung, validiert sie gegen die Produktlinie und stellt Bicep nach dem Zusammenführen des Pull Requests bereit.

Beginne infra/main.bicep mit einer Bereitstellung im Verwaltungsgruppenbereich und den erforderlichen Eingaben. Die aktuelle Modulzeile lautet:

targetScope = 'managementGroup'

param subscriptionAliasName string
param subscriptionDisplayName string
@secure()
param subscriptionBillingScope string
param subscriptionManagementGroupId string
param subscriptionWorkload string = 'Production'
param subscriptionTags object

module subVending 'br/public:avm/ptn/lz/sub-vending:0.8.0' = {
  name: 'vend-${subscriptionAliasName}'
  params: {
    resourceProviders: {}
    subscriptionAliasEnabled: true
    subscriptionAliasName: subscriptionAliasName
    subscriptionBillingScope: subscriptionBillingScope
    subscriptionDisplayName: subscriptionDisplayName
    subscriptionManagementGroupAssociationEnabled: true
    subscriptionManagementGroupId: subscriptionManagementGroupId
    subscriptionTags: subscriptionTags
    subscriptionWorkload: subscriptionWorkload
  }
}

Version 0.8.0 ist die aktuelle Modulversion dieses Trips. Vergleiche sie vor der Implementierung mit der offiziellen Registrierung und teste jede neuere Version, bevor du die festgelegte Version änderst.

Erstelle danach .github/workflows/vend-subscription.yml. Konfiguriere zwei unterschiedliche Aufgaben:

  1. Bei einem Pull Request mit Änderungen unter requests/** liest der Workflow Anforderung und Produktlinie und validiert zulässige Umgebung, Anzeigenamenmuster, erforderliche Tags, Budget und Verwaltungsgruppen-ID. Diese Aufgabe darf kein Abonnement erstellen.
  2. Nach dem Zusammenführen in main meldet sich der Workflow mit azure/login und den GitHub Secrets AZURE_CLIENT_ID sowie AZURE_TENANT_ID bei Azure an, liest die genehmigte Anforderung und startet eine Verwaltungsgruppenbereitstellung von infra/main.bicep. AZURE_BILLING_SCOPE wird aus GitHub Secrets und nicht aus einer Repositorydatei übergeben.

Verwende für die Bereitstellungsaufgabe eine explizite GitHub-Umgebung wie subscription-vending-production und konfiguriere unter Settings > Environments eine erforderliche prüfende Person. Dadurch kann ein Merge allein kein Abonnement ohne abschließende Genehmigung erstellen.

Ordne die genehmigte Anforderung den Modulparametern zu, die mindestens folgende Aufgaben ausführen:

  • das Abonnement mit dem Anzeigenamen CloudTrips TEST erstellen
  • es mg-cloudtrips-online zuordnen
  • die genehmigte verantwortliche Person oder Gruppe zuweisen
  • die erforderlichen Abonnementtags anwenden
  • das genehmigte Budget und Benachrichtigungen erstellen
  • nur die von der Produktlinie benötigten Ressourcenanbieter registrieren

Bestätige vor dem Zusammenführen, dass die Validierungsaufgabe Folgendes meldet:

Display name: CloudTrips TEST
Environment: TEST
Destination: mg-cloudtrips-online
Required tags: Present
Budget: Present
Validation: Passed

Eine autorisierte Person genehmigt anschließend den Pull Request. Wähle Merge pull request. Genehmige die geschützte GitHub-Umgebung, wenn die Bereitstellung pausiert, und beobachte den Deployment-Job bis zum erfolgreichen Abschluss.

Erfolgreicher Subscription-Vending-Pipeline-Lauf für CloudTrips TEST

Das erstellte Abonnement prüfen

Öffne nach erfolgreichem Pipeline-Lauf Management groups und erweitere:

CloudTrips
└── Landing Zones
    └── Online
        ├── CloudTrips DEV
        └── CloudTrips TEST

Öffne Subscriptions > CloudTrips TEST und prüfe:

  • eine Subscription ID ist vorhanden und der Status ist aktiv
  • die übergeordnete Verwaltungsgruppe ist Online
  • die vorgesehene verantwortliche Person oder Gruppe erscheint unter Access control (IAM)
  • die Tags Application, Environment und Owner sind vorhanden
  • Budget und Benachrichtigungsempfänger sind korrekt
  • die erwarteten Richtlinien werden von Online geerbt

Stelle keine TEST-Workloadressourcen bereit, bevor alle Prüfungen erfolgreich sind. Das Abonnement ist jetzt die TEST Application Landing Zone; die Workloadressourcen und das virtuelle TEST-Netzwerk können anschließend bereitgestellt werden.

Durch den Vending-Workflow erstelltes CloudTrips TEST unter Online

Erstelle CloudTrips PROD nicht durch das Kopieren manueller Portalschritte. Sende eine weitere Anforderung über denselben geprüften Workflow, damit PROD dieselbe Grundlage und einen nachvollziehbaren Genehmigungsdatensatz erhält.