Gewähren des Zugriffs auf Azure für einen Dienstprinzipal

  • 6 Minuten

Ein Dienstprinzipal allein ist in Ihrer Azure-Umgebung noch nicht viel wert. Ein Benutzer kann Ihre Azure-Ressourcen auch nur dann nutzen, wenn er dazu autorisiert ist. In dieser Lerneinheit erfahren Sie, wie Sie Dienstprinzipale für die Bereitstellung und Konfiguration von Azure-Ressourcen autorisieren, ohne unnötige Berechtigungen zu gewähren.

Hinweis

Die Befehle in dieser Lerneinheit dienen der Veranschaulichung der Konzepte. Führen Sie die Befehle jetzt noch nicht aus. Sie können das Erlernte in Kürze üben.

Autorisierung des Dienstprinzipals

Bisher wurde vor allem beschrieben, was Dienstprinzipale sind und wie sie verwendet werden können, um die Identität einer Pipeline für Microsoft Entra ID nachzuweisen. Hier geht es nun um die Authentifizierung.

Nachdem ein Dienstprinzipal von Microsoft Entra ID authentifiziert wurde, lautet die nächste Frage: Welche Möglichkeiten bestehen für diesen Dienstprinzipal? Dies ist das Konzept der Autorisierung. Zuständig hierfür ist das System der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) von Azure, das auch als Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) bezeichnet wird. Per Azure RBAC können Sie einem Dienstprinzipal Zugriff auf eine bestimmte Ressourcengruppe, ein Abonnement oder eine Verwaltungsgruppe gewähren.

Hinweis

Sie verwenden hier lediglich das Azure RBAC-System, um den Zugriff für die Erstellung und Verwaltung von Azure-Ressourcen, z. B. Ihre Speicherkonten, den App Service-Plan und virtuelle Netzwerke, zu gewähren. Microsoft Entra ID verfügt zudem über ein eigenes Rollensystem, das auch als Verzeichnisrollen bezeichnet wird. Sie verwenden diese Rollen, um für Dienstprinzipale Berechtigungen zum Verwalten von Microsoft Entra ID zu gewähren. In diesem Modul wird dieses Thema nicht ausführlicher beschrieben. Sie sollten aber beachten, dass der Ausdruck Rolle in der Dokumentation für beide Fälle verwendet werden kann.

Auswählen der richtigen Rollenzuweisung für Ihre Pipeline

Eine Rollenzuweisung umfasst drei wichtige Informationen: Wem die Rolle zugewiesen ist (zugewiesene Person), welche Möglichkeiten bestehen (Rolle) und für welche Ressourcen die Rollenzuweisung gilt (Bereich).

Zugewiesene Person

Wenn Sie einen Dienstprinzipal nutzen, weisen Sie ihm Rollen zu. Sie verwenden die Anwendungs-ID des Dienstprinzipals, um den richtigen Dienstprinzipal für die zugewiesene Person zu identifizieren.

Rolle

Die Ermittlung, welche Rolle zugewiesen werden soll, kann etwas mehr Aufwand bedeuten. In Azure gibt es einige allgemeine Rollen:

  • Leser: Ermöglicht der Person, der diese Rolle zugewiesen ist, das Lesen von Informationen zu Ressourcen, aber nicht das Ändern oder Löschen.
  • Mitwirkender: Ermöglicht der Person, der die Rolle zugewiesen ist, das Erstellen von Ressourcen und das Lesen und Ändern vorhandener Ressourcen. Mitwirkende können anderen Prinzipalen aber keinen Zugriff auf Ressourcen gewähren.
  • Besitzer: Ermöglicht die vollständige Kontrolle über Ressourcen, z. B. auch das Gewährens des Zugriffs für andere Prinzipale.

Achtung

Sie sollten Dienstprinzipalen nur die Mindestberechtigungen gewähren, die für die jeweiligen Aufgaben benötigt werden. In den meisten Fällen verfügt die Rolle „Besitzer“ für eine Bereitstellungspipeline über einen zu hohen Berechtigungsgrad.

Es gibt auch viele spezifische Rollen, die nur den Zugriff auf einen Teil der Funktionen ermöglichen. Sie können auch eigene benutzerdefinierte Rollendefinitionen erstellen, um die genaue Liste der Berechtigungen festzulegen, die Sie zuweisen möchten.

Hinweis

Benutzerdefinierte Rollendefinitionen können eine gute Option zum Gewähren von Berechtigungen für Ihre Azure-Ressourcen sein, aber mitunter gestaltet sich die Nutzung schwierig. Es ist nicht immer einfach, genau zu ermitteln, welche Berechtigungen Sie einer benutzerdefinierten Rollendefinition hinzufügen müssen. Es kann passieren, dass Sie den Berechtigungsgrad für die Rollendefinitionen versehentlich zu niedrig oder zu hoch wählen. Falls Sie bei der Vorgehensweise unsicher sind, sollten Sie stattdessen eine der integrierten Rollendefinitionen verwenden. Eine Beschreibung der benutzerdefinierten Rollendefinitionen würde den Rahmen dieses Moduls sprengen.

`Scope`

Sie müssen bestimmen, welchen Umfang die Zuweisung der Rolle haben soll. Diese Entscheidung wirkt sich auf die Anzahl von Ressourcen aus, die vom Dienstprinzipal geändert werden können. Häufige Bereiche:

  • Einzelne Ressource: Sie können Zugriff gewähren, der nur für eine bestimmte Ressource gilt. Für Bereitstellungspipelines wird dieser Bereich normalerweise nicht genutzt, da von einer Pipeline Ressourcen erstellt werden, die noch nicht vorhanden sind, oder es werden mehrere Ressourcen neu konfiguriert.
  • Ressourcengruppe: Sie können Zugriff auf alle Ressourcen einer Ressourcengruppe gewähren. Auch Mitwirkende und Besitzer können Ressourcen innerhalb der Gruppe erstellen. Dies ist eine gute Option für viele Bereitstellungspipelines.
  • Abonnement: Sie können Zugriff auf alle Ressourcen innerhalb eines Abonnements gewähren. Falls Sie unter einem Abonnement über mehrere Anwendungen, Workloads oder Umgebungen verfügen, können Sie Berechtigungen für den Bereich des Abonnements gewähren. Für eine Bereitstellungspipeline ist dieser Berechtigungsgrad in der Regel aber zu hoch. Sie sollten stattdessen erwägen, Ihre Rollenzuweisungen auf Ressourcengruppen zu beschränken – es sei denn, Ihr Bereitstellungsworkflow selbst muss Ressourcengruppen erstellen.

Beachten Sie hierbei, dass Rollenzuweisungen vererbt werden. Wenn Sie eine Rolle unter einem Abonnement zuweisen, hat die zugewiesene Person Zugriff auf alle Ressourcengruppen und Ressourcen dieses Abonnements.

Auswählen der richtigen Rollenzuweisung

Nachdem Sie sich nun über die Komponenten einer Rollenzuweisung informiert haben, können Sie die entsprechenden Werte für Ihre Szenarien festlegen. Hier sind einige allgemeine Richtlinien angegeben, die Sie berücksichtigen sollten:

  • Verwenden Sie die Rolle mit den geringstmöglichen Berechtigungen. Verwenden Sie nicht die Rolle „Besitzer“, wenn über Ihre Pipeline nur einfache Bicep-Vorlagen bereitgestellt und keine Rollenzuweisungen verwaltet werden sollen.
  • Verwenden Sie den geringstmöglichen Umfang. Da mit den meisten Pipelines nur Ressourcen für eine Ressourcengruppe bereitgestellt werden müssen, sollten dafür keine Rollenzuweisungen auf Abonnementebene zugewiesen werden.
  • Für viele Pipelines ist eine gute Standardoption für eine Rollenzuweisung die Rolle „Mitwirkender“ auf der Ebene der Ressourcengruppen.
  • Berücksichtigen Sie den derzeitigen und zukünftigen Zweck Ihrer Pipeline. Beispielsweise können Sie erwägen, eine benutzerdefinierte Rollendefinition für die Bereitstellungspipeline Ihrer Website zu erstellen und nur Berechtigungen für App Service und Application Insights zu gewähren. Es kann beispielsweise sein, dass Sie Ihrer Bicep-Datei nächsten Monat ein Azure Cosmos DB-Konto hinzufügen müssen, aber die Erstellung von Azure Cosmos DB-Ressourcen durch die benutzerdefinierte Rolle blockiert wird. Stattdessen ist es häufig besser, eine integrierte Rolle oder eine Kombination integrierter Rollen zu verwenden, um zu vermeiden, dass Sie ständig Ihre Rollendefinitionen ändern müssen. Erwägen Sie die Verwendung von Azure Policy, um die Durchsetzung Ihrer Governanceanforderungen in Bezug auf zulässige Dienste, SKUs und Standorte zu erzwingen.
  • Testen Sie die Pipeline, um sicherzustellen, dass die Rollenzuweisung funktioniert.

Mischen und gemeinsames Verwenden von Rollenzuweisungen

Sie können mehrere Rollenzuweisungen erstellen, mit denen unterschiedliche Berechtigungen auf unterschiedlichen Ebenen bereitgestellt werden. Beispielsweise können Sie einem Dienstprinzipal die Rolle „Leser“ mit dem Bereich „Gesamtes Abonnement“ und demselben Dienstprinzipal die Rolle „Mitwirkender“ für eine bestimmte Ressourcengruppe zuweisen. Wenn der Dienstprinzipal versucht, die Ressourcengruppe zu nutzen, wird die zugewiesene Rolle mit dem höheren Berechtigungsgrad angewendet.

Arbeiten mit mehreren Umgebungen

Sie verwenden wahrscheinlich mehrere Umgebungen für Ihre Anwendungen, z. B. Entwicklungs-, Test- und Produktionsumgebungen. Die Ressourcen für jede Umgebung sollten in unterschiedlichen Ressourcengruppen oder Abonnements bereitgestellt werden.

Sie sollten separate Dienstprinzipale für jede Umgebung erstellen und jedem Dienstprinzipal den geringstmöglichen Berechtigungsgrad gewähren, der für die jeweiligen Bereitstellungen benötigt wird. Achten Sie besonders darauf, dass Sie Berechtigungen für Produktionsbereitstellungen nicht mit Berechtigungen für andere Umgebungen mischen.

Erstellen einer Rollenzuweisung für einen Dienstprinzipal

Verwenden Sie den Befehl az role assignment create, um eine Rollenzuweisung für einen Dienstprinzipal zu erstellen. Sie müssen die zugewiesene Person, die Rolle und den Bereich angeben:

az role assignment create \
  --assignee b585b740-942d-44e9-9126-f1181c95d497 \
  --role Contributor \
  --scope "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite" \
  --description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Wir sehen uns die einzelnen Argumente an:

  • --assignee dient zum Angeben des Dienstprinzipals. Um Mehrdeutigkeiten zu vermeiden, besteht die bewährte Methode darin, die Anwendungs-ID zu verwenden.
  • --role dient zum Angeben der Rolle. Wenn Sie eine integrierte Rolle verwenden, können Sie sie anhand des Namens angeben. Wenn Sie eine benutzerdefinierte Rollendefinition verwenden, geben Sie die vollständige ID der Rollendefinition an.
  • --scope dient zum Angeben des Bereichs. In der Regel ist dies eine Ressourcen-ID für eine einzelne Ressource, eine Ressourcengruppe oder ein Abonnement.
  • --description ist eine für Menschen lesbare Beschreibung der Rollenzuweisung.

Verwenden Sie das Cmdlet New-AzRoleAssignment, um eine Rollenzuweisung für einen Dienstprinzipal zu erstellen. Sie müssen die zugewiesene Person, die Rolle und den Bereich angeben:

New-AzRoleAssignment `
  -ApplicationId b585b740-942d-44e9-9126-f1181c95d497 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite' `
  -Description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Wir sehen uns die einzelnen Argumente an:

  • -ApplicationId dient zum Angeben der Anwendungsregistrierungs-ID des Dienstprinzipals.
  • -RoleDefinitionName dient zum Angeben des Namens einer integrierten Rolle. Geben Sie bei Verwendung einer benutzerdefinierte Rollendefinition die vollständige ID der Rollendefinition an, indem Sie stattdessen das Argument -RoleDefinitionId verwenden.
  • -Scope dient zum Angeben des Bereichs. In der Regel ist dies eine Ressourcen-ID für eine einzelne Ressource, eine Ressourcengruppe oder ein Abonnement.
  • -Description ist eine für Menschen lesbare Beschreibung der Rollenzuweisung.

Tipp

Eine bewährte Methode besteht darin, eine Begründung für Ihre Rollenzuweisungen anzugeben, indem Sie eine Beschreibung einfügen. Eine Beschreibung dient als Hilfe für Benutzer, die sich die Rollenzuweisungen später ansehen. Sie enthält Informationen zum Zweck und dazu, wie Sie Ihre Entscheidungen in Bezug auf die zugewiesene Person, die Rolle und den Bereich getroffen haben.

Hinweis

Es kann einige Minuten dauern, bis Rollenzuweisungen aktiviert werden.

Erstellen eines Dienstprinzipals und einer Rollenzuweisung mit nur einem Vorgang

Sie können eine Rollenzuweisung auch gleichzeitig mit einem Dienstprinzipal erstellen. Der Code ähnelt dem Befehl, den Sie in den vorherigen Lerneinheiten zum Erstellen eines Dienstprinzipals verwendet haben. Er verfügt aber über einige zusätzliche Argumente:

az ad sp create-for-rbac \
  --name MyPipeline \
  --role Contributor \
  --scopes "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite"

$servicePrincipal = New-AzADServicePrincipal `
  -DisplayName MyPipeline `
  -Role Contributor `
  -Scope '/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite'

Gewähren des Zugriffs per Bicep

Bei Rollenzuweisungen handelt es sich um Azure-Ressourcen. Dies bedeutet, dass Sie über Bicep eine Rollenzuweisung erstellen können. Wenn Sie Ihre Ressourcengruppen per Bicep initialisieren und die Ressourcen dann mit einem Dienstprinzipal in der Ressourcengruppe bereitstellen, kann dies ggf. eine Option sein. Hier ist ein Beispiel für eine Bicep-Definition für die obige Rollenzuweisung angegeben:

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2023-04-01-preview' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment pipeline for the company\'s website needs to be able to create resources within the resource group.'
  }
}

Wir sehen uns die einzelnen Argumente an:

  • name ist ein eindeutiger Bezeichner für die Rollenzuweisung. Er muss das Format eines global eindeutigen Bezeichners (Globally Unique Identifier, GUID) haben. Es ist eine bewährte Methode, die Funktion guid() in Bicep zu verwenden, um eine GUID zu erstellen. Nutzen Sie außerdem die Prinzipal-ID, die ID der Rollendefinition und den Bereich als Seedargumente für die Funktion, um sicherzustellen, dass Sie für jede Rollenzuweisung einen eindeutigen Namen erstellen.
  • principalType sollte auf ServicePrincipal festgelegt sein.
  • roleDefinitionId ist die vollqualifizierte Ressourcen-ID für die Rollendefinition, die Sie zuweisen. Sie verwenden größtenteils integrierte Rollen und finden Informationen zur Rollendefinitions-ID in der Azure-Dokumentation zu integrierten Rollen. Die Rolle Mitwirkender verfügt beispielsweise über die Rollendefinitions-ID b24988ac-6180-42a0-ab88-20f7382dd24c. Wenn Sie sie in Ihrer Bicep-Datei angeben, drücken Sie dies mit einer vollqualifizierten Ressourcen-ID aus, z. B. /subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c.
  • principalId ist die Objekt-ID des Dienstprinzipals. Stellen Sie sicher, dass Sie nicht die Anwendungs-ID oder die Objekt-ID der Anwendungsregistrierung verwenden.
  • description ist eine für Menschen lesbare Beschreibung der Rollenzuweisung.