Gewähren des Zugriffs auf Azure für eine Workloadidentität

  • 6 Minuten

Eine Workloadidentität alleine kann in Ihrer Azure-Umgebung nichts tun, genauso wie ein Benutzer nicht mit Ihren Azure-Ressourcen arbeiten kann, wenn er nicht dazu autorisiert ist. In dieser Lerneinheit erfahren Sie, wie Sie Workloadidentitäten für die Bereitstellung und Konfiguration von Azure-Ressourcen autorisieren, ohne unnötige Berechtigungen zu gewähren.

Autorisieren von Workloadidentitäten

Bisher lag der Schwerpunkt darauf, was Workloadidentitäten sind und wie sie genutzt werden können, um die Identität eines Bereitstellungsworkflows gegenüber Microsoft Entra ID nachzuweisen. Hier geht es nun um die Authentifizierung.

Nachdem Microsoft Entra ID eine Workloadidentität authentifiziert hat, lautet die nächste Frage: Welche Aufgaben kann diese Workloadidentität ausführen? 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. Mithilfe von Azure RBAC können Sie einer Workloadidentität 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 Azure 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 Workloadidentitäten die Berechtigungen zum Verwalten von Microsoft Entra ID zu gewähren. In diesem Modul wird dieses Thema nicht im Detail beschrieben, Sie sollten aber beachten, dass der Ausdruck Rolle in einigen Dokumenten für beide Situationen verwendet wird.

Auswählen der richtigen Rollenzuweisung für Ihren Workflow

Eine Rollenzuweisung umfasst drei wichtige Teile: wem die Rolle zugewiesen ist (die zugewiesene Person), was sie damit tun kann (die Rolle) und für welche Ressourcen die Rollenzuweisung gilt (der Bereich).

Zugewiesene Person

Wenn Sie mit einer Workloadidentität arbeiten, weisen Sie dafür Rollen zu. Um eine Rolle zuzuweisen, müssen Sie zunächst einen Dienstprinzipal erstellen, mit dem Sie Ihrer Anwendung Rollen in Azure zuweisen können. Nachdem der Dienstprinzipal erstellt wurde, können Sie mit der App-ID der Anwendungsregistrierung weiterarbeiten.

Zum Erstellen eines Dienstprinzipals verwenden Sie den Befehl az ad sp create und geben die App-ID der Anwendungsregistrierung an:

az ad sp create --id A123b4567c-1234-1a2b-2b1a-1234abc12345

Zum Erstellen eines Dienstprinzipals verwenden Sie das Cmdlet New-AzADServicePrincipal und geben die App-ID der Anwendungsregistrierung an:

New-AzADServicePrincipal -AppId A123b4567c-1234-1a2b-2b1a-1234abc12345

Rolle

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

  • Leser: Ermöglicht der zugewiesenen Person das Lesen von Informationen zu Ressourcen, aber nicht deren Ändern oder Löschen.
  • Mitwirkender: Ermöglicht der zugewiesenen Person 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ähren des Zugriffs für andere Prinzipale.

Achtung

Gewähren Sie einer Workloadidentität nur die Mindestberechtigungen, die sie für die jeweiligen Aufgaben benötigt. In den meisten Fällen verfügt die Rolle „Besitzer“ für einen Bereitstellungsworkflow über einen zu hohen Berechtigungsumfang.

Es gibt auch viele spezifische Rollen, die den Zugriff auf einen Teil der Funktionen ermöglichen. Sie können sogar 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 zu ermitteln, welche Berechtigungen Sie einer benutzerdefinierten Rollendefinition hinzufügen müssen. Möglicherweise legen Sie die Rollendefinitionen versehentlich zu restriktiv oder zu freizügig fest.

Falls Sie bei der Vorgehensweise unsicher sind, sollten Sie 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 von der Workloadidentität geändert werden können. Häufige Bereiche:

  • Einzelne Ressource: Sie können Zugriff nur auf eine bestimmte Ressource gewähren. Für Bereitstellungsworkflows wird dieser Bereich normalerweise nicht genutzt, da der Workflow noch nicht vorhandene Ressourcen erstellt oder verschiedene 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 Bereitstellungsworkflows.
  • 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 einen Bereitstellungsworkflow ist dieser Berechtigungsumfang in der Regel aber zu groß. Sie sollten stattdessen erwägen, Ihre Rollenzuweisungen auf Ressourcengruppen zu beschränken – es sei denn, Ihr Bereitstellungsworkflow 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 in diesem Abonnement.

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. Wenn Ihr Workflow nur grundlegende Bicep-Dateien bereitstellt und keine Rollenzuweisungen verwaltet, sollten Sie die Rolle „Besitzer“ nicht verwenden.

  • Verwenden Sie den geringstmöglichen Umfang. Die meisten Workflows müssen nur Ressourcen für eine Ressourcengruppe bereitstellen, daher sollten ihnen keine abonnementbezogenen Rollenzuweisungen zugewiesen werden.

  • Für viele Workflows ist die Rolle „Mitwirkender“ für den Ressourcengruppenbereich eine gute Standardoption für eine Rollenzuweisung.

  • Berücksichtigen Sie alles, was Ihr Workflow tut und was er in Zukunft tun könnte. Beispielsweise können Sie erwägen, eine benutzerdefinierte Rollendefinition für den Bereitstellungsworkflow 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 den Workflow, 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. Sie können einer Workloadidentität beispielsweise die Rolle „Leser“ und als Bereich das gesamte Abonnement zuweisen. Sie können der gleichen Workloadidentität separat die Rolle „Mitwirkender“ für eine bestimmte Ressourcengruppe zuweisen. Wenn die Workloadidentität versucht, die Ressourcengruppe zu nutzen, wird die zugewiesene Rolle mit dem größeren Berechtigungsumfang 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 für jede Umgebung separate Workloadidentitäten erstellen. Gewähren Sie jeder Workloadidentität die Mindestberechtigungen, die sie für ihre Bereitstellungen benötigt. Achten Sie besonders darauf, dass Sie Berechtigungen für Produktionsbereitstellungen nicht mit Berechtigungen für andere Umgebungen mischen.

Erstellen einer Rollenzuweisung für eine Workloadidentität

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

az role assignment create \
  --assignee A123b4567c-1234-1a2b-2b1a-1234abc12345 \
  --role Contributor \
  --scope "/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite" \
  --description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

Wir sehen uns die einzelnen Argumente an:

  • --assignee gibt die Workloadidentität an. Sie können diese auf verschiedene Arten angeben, aber die Verwendung der Anwendungs-ID ist eine gute Methode, weil sie eindeutig ist.
  • --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 eine Workloadidentität zu erstellen. Geben Sie die zugewiesene Person, die Rolle und den Bereich an:

New-AzRoleAssignment `
  -ApplicationId A123b4567c-1234-1a2b-2b1a-1234abc12345 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite' `
  -Description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

Wir sehen uns die einzelnen Argumente an:

  • -ApplicationId gibt die Anwendungsregistrierungs-ID der Workloadidentität an.
  • -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.

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. Dies kann sinnvoll sein, wenn Sie Ihre Ressourcengruppen mithilfe von Bicep initialisieren und dann die Ressourcen mit einer Workloadidentität in der Ressourcengruppe bereitstellen. Hier sehen Sie ein Beispiel für eine Bicep-Definition für die obige Rollenzuweisung:

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment workflow 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 global eindeutiger Bezeichner (Globally Unique Identifier, GUID) für die Rollenzuweisung. Es empfiehlt sich, die guid()-Funktion in Bicep zu verwenden, um eine GUID zu erstellen. Um einen Namen zu erstellen, der für jede Rollenzuweisung eindeutig ist, verwenden Sie die Prinzipal-ID, die Rollendefinitions-ID und den Bereich als Startargumente für die Funktion.

  • principalType sollte auf ServicePrincipal festgelegt sein.

  • roleDefinitionId ist die vollqualifizierte Ressourcen-ID für die Rollendefinition, die Sie zuweisen. Da Sie größtenteils integrierte Rollen verwenden, finden Sie 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, verwenden Sie eine vollqualifizierte Ressourcen-ID, z. B. /subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/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.