Von Visual Studio Team Services (VSTS) aus ist es möglich, mit einem Active Directory Service Principal auf eine Azure Subscription zu deployen. Die Microsoft-Dokumentation verweist auf einen Blog-Beitrag, in dem ein 3-Klick und ein manueller Weg zur Einrichtung dieses Prinzips beschrieben wird. Obwohl die Informationen im Blog-Post für die 3-Klick-Einrichtung immer noch aktuell sind, ist der Link zum Skript für die manuelle Konfiguration nicht mehr verfügbar (nicht gefunden, wahrscheinlich weil das Git-Repository verschoben/umbenannt wurde). Bei beiden vorgeschlagenen Möglichkeiten (3-Klick oder manuell) habe ich einige Bedenken bezüglich der grundsätzlichen Einrichtung, die meiner Meinung nach verbessert werden könnten:
- Dem Principal, der während des Prozesses erstellt wird, wird die Rolle "Contributor" für das gesamte Azure-Abonnement zugewiesen, und wenn Sie das manuelle Powershell-Skript verwenden, ist die Standardrolle sogar "Owner" (dies kann geändert werden).
- Der Name der Active Directory-Anwendung/des Principals ist ein zufälliger Leitfaden, der schwer zu identifizieren ist, siehe dieses Bild:
Bei dem Kunden, für den ich derzeit arbeite, handelt es sich um ein Unternehmen, in dem mehrere Abteilungen von mehreren VSTS-Teams auf ein und dasselbe Abonnement zugreifen. Die Abonnement-Administratoren lassen aus Gründen der Sicherheit und der Fehler bei der Bereitstellung nicht zu, dass ein AD-Prinzipal Eigentümer/Beteiligter des gesamten Abonnements ist. Ich stimme ihnen zu, denn eine Abteilung kann über eine VSTS-Bereitstellung versehentlich Ressourcengruppen/Ressourcen ändern, löschen oder aktualisieren, die ihr nicht gehören. Mein Vorschlag an die Azure-Administratoren war, mehrere Principals zu erstellen, deren Rolle nur für bestimmte Ressourcengruppen gilt, die den Abteilungen gehören. Auf diese Weise kann jedes VSTS-Team einen VSTS-Endpunkt mit einem Principal konfigurieren, der über ausreichende Rechte verfügt, um nur für seine Ressourcengruppen zu arbeiten. Deshalb habe ich ein verbessertes Powershell-Skript erstellt (basierend auf dem manuellen Skript von Microsoft), das versucht, die Principal-Erstellung anhand meines Vorschlags zu automatisieren.
Meine Powershell-Kenntnisse sind begrenzt, also helfen Sie mir bitte, das Skript zu verbessern, wenn Sie denken, dass es besser gemacht werden kann. Hier ist das GitHub-Repositorium, Sie können es gerne forken/klonen und Pull Requests bereitstellen.
Wie immer, wenn es um Sicherheitsfragen geht, erfordert die Einrichtung ein wenig mehr manuellen Aufwand, aber mein Powershell-Skript versucht, es so einfach wie möglich zu machen. Das Powershell-Skript führt Folgendes aus:
- Erstellen Sie ein AD Service Principal mit einem bestimmten Namen und Kennwort (keine seltsamen Kennungen mehr, der Name liegt in Ihrer Hand, dem Namen wird "VSTS." vorangestellt).
- Die Rolle (Eigentümer, Mitwirkender usw.) kann angegeben werden.
- Über eine Reihe von Parametern können Sie die Namen der Ressourcengruppen angeben, für die die Rolle für diesen Principal gewährt wird.
- Erstellen Sie schließlich die Ressourcengruppen, wenn sie noch nicht existieren.
- Wenn Sie dennoch einen Principal mit einer auf Abonnementebene gewährten Rolle erstellen möchten, ist dies immer noch möglich.
- Wenn die AD-Anwendung, der Principal, die Rollenzuweisung und die Ressourcengruppen bereits vorhanden sind, wird ihre Erstellung übersprungen.
Verwendung des Powershell-Skripts
Das Powershell-Skript verwendet Parametersets für die Argumente. Hier sind die Beispiele mit einer Beschreibung für die Aufrufe unter Verwendung der verschiedenen Parametersets:
Die zugewiesene Rolle ist standardmäßig "Contributor", Sie können sie mit dem Parameter $spnRole überschreiben (wie -spnRole "owner")
CreateVSTSPrincipalOnly
Erstellen Sie nur eine AD-Anwendung/Prinzipal ohne Rollenvergabe:
.createvstsprincipal.ps1 -subscriptionName "Der Abonnementname" -applicationName "DerAnwendungsname" -password "DasKennwort"
CreateVSTSPrincipalWithExistingResourceGroups
Erstellen Sie eine AD-Anwendung/ein AD-Prinzipal und gewähren Sie die Rolle für die angegebenen bestehenden Ressourcengruppen (wenn die Ressourcengruppen nicht existieren, wird kein Fehler ausgegeben, sie werden einfach ignoriert):
.createvstsprincipal.ps1 -subscriptionName "Der Abonnementname" -applicationName "DerAnwendungsname" -password "DasPasswort" -resourceGroupNames "ResourceGroupName1", "ResourceGroupName2", "etc"
CreateVSTSPrincipalAndResourceGroups
Erstellen Sie eine AD-Anwendung/ein AD-Prinzipal und die angegebenen Ressourcengruppen an dem angegebenen Ort und weisen Sie den Ressourcengruppen die Rolle zu:
.createvstsprincipal.ps1 -subscriptionName "Der Abonnementname" -applicationName "DerAnwendungsname" -password "DasPasswort" -resourceGroupNames "ResourceGroupName1", "ResourceGroupName2", "etc" -createResourceGroups -location "West Europe"
CreateVSTSPrincipalSubscriptionLevel
Wie die Original-Powershell von Microsoft erstellt dies eine AD-Anwendung/Prinzipal und gewährt die Rolle auf Abonnementebene:
.createvstsprincipal.ps1 -subscriptionName "Der Abonnementname" -applicationName "DerAnwendungsname" -password "DasPasswort" -grantRoleOnSubscriptionLevel
Wenn eine (neue) Abteilung/VSTS-Team in einer (neuen) Ressourcengruppe eingesetzt werden muss, kann der Azure-Administrator das Skript erneut ausführen. Wichtig ist, dass Sie denselben Anwendungsnamen angeben.
Konfigurieren des Principal in VSTS
Die Powershell-Skripte geben alle Informationen aus, die in VSTS benötigt werden:
Richten Sie in VSTS einen neuen Azure RM-Endpunkt ein:
klicken Sie auf "hier klicken":
Und nun kopieren Sie aus der Skriptausgabe der Powershell und fügen sie ein:
Fazit
Mit der von mir erstellten Powershell ist es möglich, die Azure-Ressourcen, auf die der VSTS-Principal Zugriff hat, genauer zu steuern, wodurch die Bereitstellung sicherer und die Azure-Administratoren zufriedener werden 
Verfasst von
Marco Mansi
Contact