Grundlegendes zu Workloadidentitäten

7 Minuten

Bereitstellungsworkflows, Anwendungen und Software erfordern eine besondere Möglichkeit zur Authentifizierung. In dieser Lerneinheit wird beschrieben, warum Workloadidentitäten für Bereitstellungsworkflows wichtig sind, wie sie zum Azure-Sicherheitsmodell passen und wie sie funktionieren.

Warum muss für einen Workflow eine Authentifizierung durchgeführt werden?

Wenn Sie eine Bicep-Datei bereitstellen, ist dies praktisch eine Aufforderung an Azure Resource Manager, Ihre Azure-Ressourcen zu erstellen oder zu ändern. Im Beispielszenario haben Sie eine Bicep-Datei erstellt, um die Website Ihres Spielzeugunternehmens bereitzustellen. Mit der Bicep-Datei werden Ressourcen deklariert, die einen Azure App Service-Plan, eine App und eine Application Insights-Instanz enthalten.

Wenn Sie die Datei bereitstellen, wird von Resource Manager überprüft, ob die Ressourcen vorhanden sind. Wenn nicht, werden sie von Resource Manager erstellt. Wenn bereits Ressourcen vorhanden sind, stellt Resource Manager sicher, dass deren Konfiguration mit der Konfiguration, die Sie in der Bicep-Datei angegeben haben, übereinstimmt.

Für diese Vorgänge ist jeweils eine Berechtigung erforderlich, da sie auf Ihre Azure-Ressourcen zugreifen und diese ändern. Welche Berechtigungen für die Bereitstellung jeweils erforderlich sind, richtet sich nach dem Inhalt der Bicep-Datei. Zum Bereitstellen der Beispieldatei für die Website Ihres Spielzeugunternehmens benötigen Sie die folgenden Berechtigungen innerhalb der Ressourcengruppe, für die Sie die Bereitstellung durchführen:

Möglichkeit zum Erstellen von Bereitstellungen. Bereitstellungen sind Ressourcen mit dem Typ Microsoft.Resources/deployments.
Möglichkeit zum Erstellen und Ändern von App Service-Plänen und -Apps.
Möglichkeit zum Erstellen und Ändern von Application Insights-Instanzen.

Bisher haben Sie Ihre Bicep-Dateien wahrscheinlich selbst bereitgestellt, indem Sie die Azure CLI oder Azure PowerShell verwendet haben. Bei Verwendung dieser Tools nutzen Sie normalerweise Ihr eigenes Benutzerkonto und führen die Authentifizierung über Ihren Browser durch. Dies wird als die Verwendung Ihrer eigenen Identität bezeichnet. Wenn Sie eine Bereitstellung übermitteln, wird von Azure überprüft, ob Ihre Identität über die erforderlichen Berechtigungen verfügt, die für die Vorgänge in Ihrer Bicep-Vorlage benötigt werden.

Nach der Umstellung auf einen GitHub Actions-Bereitstellungsworkflow müssen Sie eine andere Art von Identität verwenden, weil der Workflow Bereitstellungen ohne Ihre direkte Beteiligung durchführt.

Typen von Identitäten

Microsoft Entra ID ist der Dienst, der Identitäten für Azure verwaltet. Einige Haupttypen von Identitäten:

Benutzeridentitäten: Ein Benutzer stellt eine Person dar, die sich normalerweise interaktiv über einen Browser anmeldet. Benutzer müssen beim Anmelden häufig zusätzliche Sicherheitsüberprüfungen durchführen, z. B. Multi-Faktor-Authentifizierung (MFA) und bedingter Zugriff je nach Standort oder Netzwerk.
Gruppen: Eine Gruppe stellt eine Sammlung von Benutzern dar. Für Gruppen wird keine direkte Authentifizierung durchgeführt, aber sie stellen eine bequeme Möglichkeit dar, einer Gruppe von Benutzern auf einmal Berechtigungen zu gewähren.
Workloadidentitäten: Eine Workload steht für einen automatisierten Prozess oder ein System, der bzw. das normalerweise nicht direkt von einer Person ausgeführt wird. Eine Workload kann sich bei Microsoft Entra ID anmelden, aber die Anmeldung und Interaktion mit dem Authentifizierungsprozess erfolgen nicht über eine Person. Workloadidentitäten verfügen nicht über MFA oder ähnliche Schutzmaßnahmen, weil hierfür eine Person Schritte ausführen muss, um ihre Identität nachzuweisen.

Im Mittelpunkt dieses Moduls stehen Workloadidentitäten.

Verwaltete Identitäten

Eine verwaltete Identität ist einer Azure-Ressource zugeordnet. Azure verwaltet die Anmeldeinformationen automatisch. Wenn die Ressource Zugriff benötigt, meldet sich Azure automatisch mit den Anmeldeinformationen an.

Verwaltete Identitäten sind für in Azure gehostete Ressourcen wie virtuelle Computer und App Service-Apps verfügbar. Sie stellen eine hervorragende Möglichkeit für Azure-Ressourcen dar, in den folgenden Situationen die Authentifizierung durchzuführen: Automatisieren Ihrer Azure-Verwaltung, Herstellen einer Verbindung mit Datenbanken und Lesen von Geheimnisdaten aus Azure Key Vault. Sie können verwaltete Identitäten mit Azure Arc auch für andere Szenarien verwenden.

Bei der Arbeit mit Bereitstellungsworkflows verwenden Sie in der Regel keine verwalteten Identitäten. Für verwaltete Identitäten ist es erforderlich, dass Sie die Azure-Ressourcen, die Ihre Bereitstellungen ausführen, besitzen und verwalten. Beim Arbeiten mit GitHub Actions nutzen Sie in der Regel die freigegebene Infrastruktur, die von Microsoft oder GitHub bereitgestellt wird. Wenn Sie jedoch eine Workloadidentität mit GitHub Actions verwenden, können Sie den Hauptvorteil verwalteter Identitäten nutzen: Sie müssen keine Anmeldeinformationen verwalten.

Tipp

Falls Sie in anderen Bereichen Ihrer Lösung die Wahl zwischen der Verwendung einer verwalteten Identität und eines normalen Dienstprinzipals haben, entscheiden Sie sich am besten für eine verwaltete Identität. Verwaltete Identitäten sind leichter zu handhaben und in der Regel auch sicherer.

Warum können Sie nicht einfach Ihr Benutzerkonto verwenden?

Vielleicht fragen Sie sich, warum Sie nur für die Authentifizierung eines Bereitstellungsworkflows diese ganz neue Art von Objekt erstellen müssen, wo Sie doch über gut funktionierende Benutzerkonten verfügen.

Benutzerkonten sind nicht für die unbeaufsichtigte Nutzung ausgelegt. Beim Authentifizierungsprozess für ein Benutzerkonto wird häufig überprüft, ob es sich bei der Entität, von der der Anmeldungsversuch unternommen wird, um einen Menschen handelt. Organisationen nutzen während der Authentifizierung zunehmend zusätzliche Sicherheitsüberprüfungen. Beispiele hierfür sind MFA, CAPTCHA-Überprüfungen und die Untersuchung des von der Benutzerin oder dem Benutzer verwendeten Geräts und Netzwerks, damit die Zulässigkeit einer Anmeldeanforderung verifiziert werden kann.

Workflows sind so konzipiert, dass Ihre Bereitstellungen auch dann ausgeführt werden, wenn kein Benutzer diese Ausführungen aktiv anstößt. Die meisten Vorteile von Bereitstellungsworkflows beruhen tatsächlich darauf, dass sie automatisiert sind und keine Eingriffe durch Personen erfordern.

Wenn Sie Ihren Benutzernamen und Ihr Kennwort in einem Workflow speichern und versuchen, diese Angaben für die Anmeldung zu verwenden, funktioniert dies wahrscheinlich nicht. Auch wenn dieser Ansatz anfänglich zu funktionieren scheint, ist dies für den weiteren Verlauf nicht sichergestellt, falls von Microsoft Entra ID oder vom Administrator Ihrer Organisation weitere Sicherheitsüberprüfungen für den Prozess der Benutzerauthentifizierung hinzugefügt werden.

Warnung

Es ist auch nicht ratsam, Ihren Benutzernamen und das Kennwort an einem anderen Ort zu speichern, weil eine andere Person unter Umständen Zugriff auf diese Daten erlangen und dann verwenden kann, um sich als Sie auszugeben.

Aus diesen Gründen können Sie bei den integrierten GitHub Actions-Aufgaben, die mit Azure interagieren, nicht die Anmeldeinformationen eines Benutzerkontos angeben. Sie erfordern die Verwendung einer Workloadidentität.

Wie funktionieren Workloadidentitäten?

Workloadidentitäten sind eine Funktion von Microsoft Entra ID, einem globalen Identitätsdienst. Viele Unternehmen verwenden Microsoft Entra ID, und jedes dieser Unternehmen wird als Mandant bezeichnet.

Microsoft Entra ID beinhaltet ein Anwendungskonzept. Eine Anwendung stellt ein System, eine Softwarekomponente, einen Prozess oder eine andere nicht menschliche Komponente dar. Sie können sich einen Bereitstellungsworkflow auch als Anwendung vorstellen.

Wenn Sie eine Anwendung erstellen und Microsoft Entra ID darüber informieren, erstellen Sie ein Objekt, das als Anwendungsregistrierung bezeichnet wird. Eine Anwendungsregistrierung steht für die Anwendung in Microsoft Entra ID.

Einer Anwendungsregistrierung können Verbundanmeldeinformationen zugeordnet sein. Für Verbundanmeldeinformationen müssen keine Geheimnisse gespeichert werden. Stattdessen ermöglichen sie die Verwendung einer Microsoft Entra-Anwendung mit einem unterstützten Dienst wie GitHub.

Wenn Ihr GitHub Actions-Workflow authentifiziert werden muss, kontaktiert er Microsoft Entra ID über GitHub. GitHub teilt Microsoft Entra ID den Namen der GitHub-Organisation und des -Repositorys sowie optional weitere Informationen mit. Wenn Sie Verbundanmeldeinformationen konfiguriert haben, die den Details des Repositorys entsprechen, authentifiziert Microsoft Entra Ihren Bereitstellungsworkflow. Der Workflow kann die Berechtigungen verwenden, die Sie der Anwendung zugewiesen haben.

Tipp

Bei der Betrachtung einer Anwendungsregistrierung im Azure-Portal sehen Sie noch viele weitere Funktionen und Konfigurationen, die Ihnen unter Umständen nicht relevant erscheinen. In Microsoft Entra ID sind mit Anwendungen viele Dinge möglich, die über den Bereich von Authentifizierungs- und Workflowbereitstellungen hinausgehen.

Sie können auch ein Dienstprinzipalobjekt in Ihrem Microsoft Entra-Mandanten erstellen. Ein Dienstprinzipal ist wie eine Kopie der Anwendung, die von Ihrem eigenen Microsoft Entra-Mandanten verwendet werden kann. Dienstprinzipale und Anwendungen sind eng miteinander verknüpft. Sie verwenden einen Dienstprinzipal später in diesem Modul, wenn Sie Ihre Workflowberechtigung für den Zugriff auf Azure erteilen.

Hinweis