Neue Sandbox-Subscription¶

Work in progress. Dieses Runbook ist eine allgemeine Anleitung. Das vorgesehene Design ist ein Deployment wie bei einem spoke, aber nur mit einer subscription und ohne spoke canvas. Dieser Ablauf existiert im Code noch nicht. Unten steht, was mit dem aktuellen Code möglich ist und was du von Hand erledigen musst.

Standardänderung: Neue Azure-Sandbox-Subscription

Vorgesehene Auswirkung: Eine neue subscription für Experimente, platziert in der Management Group sandbox, mit Zugriff für das anfragende Team. Sie erhält keine hub-Anbindung, kein virtuelles Netzwerk und keine spoke-Ressourcen.

Anfragefelder¶

Feld	Verwendung
Subscription Name	Anzeigename der subscription
Begründung	Change-Record
Environment	Plattformumgebung (`canary` / `prod`), deren Management Group `sandbox` verwendet wird
Which team needs access	Entra-ID-Gruppe, die Zugriff erhält
Kommentare

Was der aktuelle Code unterstützt¶

Bedarf	Vom Code unterstützt?	Vorgehen
Die subscription erstellen	Nein (nicht über die pipelines, siehe New spoke)	Erstelle sie über deinen EA/MCA/CSP-Prozess.
In der Management Group `sandbox` platzieren	Ja	`foundation`-Layer: `management_group_structure.sandbox.subscription_ids`
Team-Zugriff (RBAC/PIM)	Nein	Weise Rollen von Hand zu oder über deinen Identity-Governance-Prozess.
Tags	Nein	Setze sie von Hand.
Policies und Monitoring	Geerbt	Alles, was an der Management Group `cloudplatform` zugewiesen ist, gilt, einschließlich der Built-in-Compliance-Initiativen und der Service-Health-Alert-Initiative, falls dort aktiviert. Zuweisungen auf `landingzones` gelten nicht.

Alternative: ein Spoke ohne Hub-Anbindung¶

Wenn das Experiment die Spoke-Baseline braucht (Netzwerk, Gruppen, Key Vault, Log Analytics), aber nicht mit dem hub oder anderen Netzwerken verbunden sein darf, erstelle einen normalen Spoke in einer Sandbox-Management-Group und setze peerHub in seinem Netzwerk auf false (siehe Spoke-JSON-Referenz). Der Spoke hat dann keine Virtual-Hub-Verbindung und damit keine Route zu anderen Spokes, zu On-Premises-Netzwerken oder (über die hub-firewall) ins Internet. Prüfe das DNS- und Routing-Verhalten eines solchen Spokes, bevor du einem Team zusagst, dass es funktioniert.

Schritte¶

Erstelle die subscription über deinen Billing-Prozess. Notiere ihre subscription-ID.
Füge sie zur Sandbox-Management-Group hinzu. Hänge in <env-folder>/<primary region>/foundation.auto.tfvars die ID an die Liste an:

management_group_structure = {
  # ...
  sandbox = {
    id               = "cloudplatform-sandbox"
    display_name     = "Sandbox"
    subscription_ids = [
      "11111111-1111-1111-1111-111111111111",
      "22222222-2222-2222-2222-222222222222"   # new
    ]
  },
  # ...
}

Führe hub aus und lies den foundation-Plan für die primäre Region. Erwartet wird eine hinzugefügte azurerm_management_group_subscription_association.
Zugriff vergeben von Hand: Weise der Entra-ID-Gruppe des Teams eine Rolle auf der subscription zu, zum Beispiel Contributor. Verwende PIM, wenn deine Organisation es verlangt.
Halte subscription, Owner und Ablaufdatum im Change-Ticket fest. Sandboxes überleben ihren Zweck erfahrungsgemäß.

Fallstricke bei `subscription_ids`¶

Aus infra/modules/management_groups/main.tf:

resource "azurerm_management_group_subscription_association" "this" {
  count           = length(var.management_group_subscription_association_subscription_ids)
  subscription_id = "/subscriptions/${element(var..._subscription_ids, count.index)}"
  lifecycle {
    ignore_changes = [management_group_id, subscription_id]
  }
}

Die Associations werden über die Listenposition (count.index) adressiert, und Änderungen an subscription_id werden ignoriert.
Hänge nur am Ende der Liste an. Entferne oder sortiere niemals Einträge um. Das Entfernen eines Eintrags aus der Mitte verschiebt die Positionen. Terraform zerstört dann die letzte Association, wodurch diese subscription aus der Management Group verschoben wird. Die übrigen Positionen behalten im state ihre alte subscription.
Um eine subscription aus sandbox herauszunehmen, verschiebe sie in Azure (portal oder CLI) und lass die Liste unverändert. Oder plane die Änderung und lies den foundation-Plan sehr sorgfältig.

Eine Sandbox-Subscription entfernen¶

Verschiebe sie in die Management Group decommissioned:
von Hand, oder
indem du ihre ID an decommissioned.subscription_ids anhängst, mit denselben Fallstricken wie oben.
Kündige sie über deinen Billing-Prozess.