Grundlegendes zu Dienstprinzipalen
Dienstprinzipale stellen eine Möglichkeit für die Authentifizierung von Pipelines, Anwendungen und Software dar. In dieser Lerneinheit wird beschrieben, warum Dienstprinzipale für Bereitstellungspipelines wichtig sind, wie sie zum Azure-Sicherheitsmodell passen und wie sie funktionieren.
Warum muss für eine Pipeline die Authentifizierung durchgeführt werden?
Wenn Sie eine Bicep-Vorlage bereitstellen, ist dies praktisch eine Aufforderung an Azure Resource Manager, Ihre Azure-Ressourcen zu erstellen oder zu ändern. In diesem Beispielszenario haben Sie eine Bicep-Vorlage erstellt, um die Website Ihres Spielzeugunternehmens bereitzustellen. Mit der Bicep-Vorlage werden Ressourcen deklariert, die einen Azure App Service-Plan, eine App und eine Application Insights-Instanz enthalten.
Wenn Sie die Vorlage bereitstellen, wird von Resource Manager überprüft, ob die Ressourcen vorhanden sind. Wenn nicht, werden sie von Resource Manager erstellt. Falls einige Ressourcen bereits vorhanden sind, wird von Resource Manager sichergestellt, dass ihre Konfiguration mit der Konfiguration übereinstimmt, die Sie in der Vorlage angeben.
Für diese Vorgänge sind Berechtigungen erforderlich, da sie auf Ihre Azure-Ressourcen zugreifen und diese ändern. Welche Berechtigungen für die Bereitstellung jeweils erforderlich sind, richtet sich danach, was die Vorlage enthält. Zum Bereitstellen der Bicep-Beispielvorlage 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 werden als Ressourcen mit dem Typ
Microsoft.Resources/deploymentsangesehen. - 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-Vorlagen wahrscheinlich selbst bereitgestellt, indem Sie die Azure CLI oder Azure PowerShell genutzt 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 eine Pipeline müssen Sie eine andere Art von Identität verwenden, da die Pipeline selbst Bereitstellungen ohne Ihre direkte Beteiligung durchführt.
Arten von Sicherheitsprinzipalen
Microsoft Entra ID ist der Dienst, der Identitäten für Azure verwaltet. Microsoft Entra ID verfügt über mehrere Arten von Identitäten, die auch als Sicherheitsprinzipale bezeichnet werden:
- Als Benutzer wird ein Mensch bezeichnet, der sich normalerweise interaktiv über einen Browser anmeldet. Benutzer müssen beim Anmelden oftmals zusätzliche Sicherheitsüberprüfungen durchführen. Beispiele wären etwa die mehrstufige Authentifizierung (Multi-Factor Authentication, MFA) und bedingter Zugriff je nach Standort oder Netzwerk.
- Eine Gruppe enthält mehrere Benutzer. 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.
- Ein Dienstprinzipal steht für einen automatisierten Prozess oder ein System, der bzw. das normalerweise nicht direkt von einem Menschen ausgeführt wird.
- Eine verwaltete Identität ist eine besondere Art von Dienstprinzipal für Situationen, in denen kein Mensch am Authentifizierungsprozess beteiligt ist.
Dienstprinzipale
Ein Dienstprinzipal ist eine Art von Konto. Die Anmeldung bei Microsoft Entra ID ist möglich, aber die Anmeldung und Interaktion mit dem Authentifizierungsprozess erfolgen nicht über eine Person. Dienstprinzipale verfügen nicht über MFA oder ähnliche Schutzmaßnahmen, da hierfür eine Person Schritte ausführen muss, um ihre Identität nachzuweisen.
In Microsoft Entra ID wird ein Dienstprinzipal basierend auf einer Anwendungs-ID und Anmeldeinformationen identifiziert. Die Anwendungs-ID ist eine global eindeutige ID (GUID). Bei Pipelines handelt es sich bei den Anmeldeinformationen normalerweise um ein sicheres Kennwort, das als Schlüssel bezeichnet wird. Alternativ können Sie auch ein Zertifikat als Anmeldeinformation verwenden.
Verwaltete Identitäten
Im Gegensatz zu anderen Dienstprinzipals ist es bei einer verwalteten Identität nicht erforderlich, dass Sie die zugehörigen Anmeldeinformationen kennen oder verwalten. 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 Verwendung von Pipelines können Sie in der Regel keine verwalteten Identitäten nutzen. Für verwaltete Identitäten ist es nämlich erforderlich, dass Sie die Azure-Ressourcen besitzen und verwalten, über die Ihre Bereitstellungen ausgeführt werden. Bei der Arbeit mit Azure Pipelines nutzen Sie in der Regel die freigegebene Infrastruktur von Microsoft.
Hinweis
Es gibt einige Situationen, in denen Pipelines verwaltete Identitäten verwenden können. In Azure Pipelines können Sie einen selbstgehosteten Agent erstellen, um die Skripts und den Code Ihrer Pipeline auszuführen, indem Sie Ihren eigenen Azure-basierten virtuellen Computer verwenden. Da Sie der Besitzer des virtuellen Computers sind, können Sie ihm eine verwaltete Identität zuweisen und ihn über Ihre Pipeline verwenden.
In den meisten Fällen werden Ihre Pipelines jedoch mit einem gehosteten Agent ausgeführt, d. h. mit einem von Microsoft verwalteten Server. Gehostete Agents sind derzeit nicht mit verwalteten Identitäten kompatibel.
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 einer Pipeline 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 immer öfter zusätzliche Sicherheitsüberprüfungen. Beispiele hierfür sind MFA, CAPTCHA-Überprüfungen und die Untersuchung des vom Benutzer verwendeten Geräts und Netzwerks, damit die Zulässigkeit einer Anmeldeanforderung verifiziert werden kann.
Pipelines sind so konzipiert, dass Ihre Bereitstellungen auch dann ausgeführt werden, wenn niemand diese Ausführungen aktiv anstößt. Die meisten Vorteile von Pipelines beruhen wirklich darauf, dass sie vollständig automatisiert sind und keine Eingriffe durch Menschen erfordern. Wenn Sie Ihren Benutzernamen und Ihr Kennwort in einer Pipeline 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 Pipelineaufgaben, die mit Azure interagieren, keine Anmeldeinformationen eines Benutzerkontos angeben. Es ist erforderlich, dass Sie einen Dienstprinzipal verwenden.
Wie funktionieren Dienstprinzipale?
Bei der Verwendung von Dienstprinzipalen oder von Tools wie dem Azure-Portal oder der Microsoft Graph-API begegnen Ihnen unter Umständen unterschiedliche Begriffe. Es ist für die Nutzung von Dienstprinzipalen in einer Pipeline zwar nicht unbedingt erforderlich, dass Sie mit diesen Begriffen vollständig vertraut sind, aber es ist hilfreich, wenn Sie über einige Informationen zu den Konzepten verfügen.
Dienstprinzipale sind ein Feature von Microsoft Entra ID. Microsoft Entra ID ist ein globaler 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 eine Bereitstellungspipeline als Anwendung vorstellen.
In Microsoft Entra ID können Anwendungen viele Aufgaben ausführen, die über den Umfang der Authentifizierung und Pipelinebereitstellungen hinausgehen. Wenn Sie eine Anwendung erstellen und Microsoft Entra ID darüber informieren, erstellen Sie ein Objekt, das als Anwendungsregistrierung bezeichnet wird. Eine Anwendungsregistrierung repräsentiert die Anwendung in Microsoft Entra ID.
Dienstprinzipale und Anwendungen sind eng miteinander verknüpft. Wenn eine Anwendungsregistrierung zu einem Microsoft Entra-Mandanten hinzugefügt wird, wird in diesem Microsoft Entra-Mandanten ein Objekt vom Typ Dienstprinzipal erstellt. Bei der Betrachtung eines Dienstprinzipals im Azure-Portal sehen Sie noch viele weitere Funktionen und Konfigurationen, die Ihnen unter Umständen als nicht relevant erscheinen. Dies liegt größtenteils daran, dass Dienstprinzipale mit Anwendungen verknüpft sind.
Wenn Sie einen Dienstprinzipal erstellen, wird bei den meisten verwendeten Tools gleichzeitig auch eine Anwendungsregistrierung erstellt. Sie merken also ggf. nicht, dass zwei verschiedene Objekte vorhanden sind.
Es gibt eine Art von Dienstprinzipal, der nicht einer Anwendungsregistrierung zugeordnet ist: eine verwaltete Identität. Wie bereits erwähnt wurde, werden die Konfiguration und die Anmeldeinformationen für eine verwaltete Identität von Azure verwaltet.
Hinweis
Ein Dienstprinzipal wird manchmal auch als Unternehmensanwendung bezeichnet. Welcher Name verwendet wird, hängt vom jeweiligen Tool ab. Es kann auch sein, dass Dienstprinzipale als verwaltete Anwendungen in Ihrem lokalen Verzeichnis bezeichnet werden, aber dies ist nicht dasselbe wie verwaltete Identitäten.
Dies lässt sich also wie folgt zusammenfassen: Bei der Erstellung eines Dienstprinzipals erstellen Sie zunächst eine Anwendungsregistrierung und dann einen Dienstprinzipal, der von dieser Anwendungsregistrierung verwendet werden kann. Da die meisten Tools, mit denen Sie arbeiten, diesen Schritt für Sie ausführen, bemerken Sie dies normalerweise gar nicht. Unter Umständen verwenden Sie nicht alle Features von Microsoft Entra-Anwendungen, wenn Sie mit Bereitstellungspipelines arbeiten. Da Dienstprinzipale mit Anwendungen verknüpft sind, gilt trotzdem die gleiche Microsoft Entra-Objektstruktur.