Africa Studio - stock.adobe.com
Nutzen Sie die Vorteile von Dienstprinzipalen in Azure
Mit Dienstprinzipalen lassen sich Schritte in Azure automatisieren, für die Anmeldeinformationen notwendig sind, ohne diese ins Skript aufzunehmen. Wir erklären, wie das geht.
Manche IT-Administratoren verwenden in Automatisierungsskripten fest kodierte Kennwörter. Das kann jedoch Sicherheitslücken öffnen. In Azure beseitigen Dienstprinzipale dieses Risiko.
Ein Dienstprinzipal in Azure Active Directory (Azure AD) ist eine Form der Sicherheitsidentität. Administratoren weisen einem Objekt, zum Beispiel einem automatisierten Tool, einer Anwendung oder einer Virtuellen Maschine (VM), einen Azure-Serviceprinzipal zu. Dann verwenden sie rollenbasierte Zugriffskontrollen (Role Based Access Control, RBAC), um den Zugriff dieses Objekts auf Azure-Ressourcen zu verwalten, statt Anmeldeinformationen in Skripten zu verwenden.
Admins erstellen einen Dienstprinzipal in jedem Tenant – oder einer dedizierten Azure-AD-Instanz – der eine Anwendung verwendet. Eine Single-Tenant-Anwendung benötigt somit einen Dienstprinzipal. Eine mandantenfähige Anwendung erfordert einen Dienstprinzipal in jedem Mandanten. Um Dienstprinzipale besser zu verstehen, werden wir ein Beispiel durchgehen und zeigen, wie er mit verwalteten Identitäten zusammenhängt.
So verwenden Sie einen Dienstprinzipal
Ein Azure-Dienstprinzipal könnte beispielsweise nützlich sein, wenn ein Administrator Terraform verwenden möchte, um eine Azure-Cloud-Umgebung zu erstellen oder zu aktualisieren, ohne Anmeldeinformationen bereitstellen zu müssen. Er sollte das Terraform-Skript so schreiben, dass darin keine Benutzernamen und keine Kennwörter zu finden sind.
Schritt 1. Um einen Dienstprinzipal zu erstellen und zu verwenden, gehen Sie zum Azure-Portal. Öffnen Sie dann die BASH-Befehlszeilenschnittstelle (Command Line Interface, CLI). Geben Sie den folgenden Befehl ein und ersetzen Sie den Platzhalter ttbeispielDP durch Ihren eigenen, spezifischeren Namen für den Dienstprinzipal:
az ad sp create-for-rbac --name "ttbeispielDP"
Die Verarbeitung des Befehls wird einige Minuten dauern. Beachten Sie die Warnung über Rollenzuweisungen in Abbildung 1.
Diese Warnung tritt auf, weil Azure dem Dienstprinzipal standardmäßig die Rolle Mitwirkender (Contributor) zuweist. Diese Rolle gewährt einem Dienstprinzipal die Berechtigung, Informationen zu lesen sowie Informationen und Objekte zu schreiben oder zu ändern. Um diese Berechtigungen einzuschränken, ändern Sie die Rolle in Leser (Reader), die nur Leseberechtigungen einräumt. Geben Sie den folgenden Befehl ein, um beim Erstellen eines Dienstprinzipals die Rolle Reader zuzuweisen:
az ad sp create-for-rbac --role reader --name "ttbeispielDP"
Schritt 2. Verwenden Sie die in Abbildung 1 gezeigten Anmeldeinformationen in der Anwendung, die sie unterstützt und nach ihnen fragt. Notieren Sie sich die Informationen sorgfältig, da sie sonst nirgends mehr einzusehen sein werden. Standardmäßig haben Dienstprinzipale eine Lebensdauer von einem Jahr, bevor das Kennwort abläuft. Das Kennwort funktioniert nur mit dem Dienstprinzipalkonto und ist erforderlich, um ein Skript auszuführen.
Schritt 3. Nachdem Sie Azure CLI heruntergeladen und installiert haben, verwenden Sie den folgenden Befehl, um sich anzumelden und die Anmeldedaten des Dienstprinzipals zu testen. Geben Sie die app_id, das Passwort und die tenant_id an (unten gefettet):
az login -service-principal --username app_id --password password --tenant tenant_id
Um den aktuellen Anmeldestatus zu sehen und zu überprüfen, ob das System verbunden ist, verwenden Sie az account show, wie in Abbildung 2 gezeigt.
Jeder ausgegebene Befehl nutzt die zugewiesenen Anmeldedaten. Wenn Administratoren zum Beispiel einem Serviceprinzipal die Rolle Leser zuweisen, gewähren sie dem Mandanten nur Leserechte. Admins können diese Berechtigungen auf bestimmte Verwaltungsgruppen oder einzelne Ressourcen wie VMs oder Load Balancer beschränken.
Azure Service Principals versus verwaltete Identitäten
Dienstprinzipale sind nur eine Form der Sicherheitsidentität in Azure – eine andere sind verwaltete Identitäten. Sie bieten eine Identität für Anwendungen, die auf Azure-Ressourcen zugreifen. Sowohl Dienstprinzipale als auch verwaltete Identitäten ermöglichen einen fein abgestuften, programmatischen Zugriff auf die Azure-Infrastruktur, ohne dass Sie Passwörter in Skripte eingeben müssen.
Verwaltete Identitäten können systemzugeordnet oder benutzerzugeordnet sein. Bei systemzugewiesenen verwalteten Identitäten erstellen Administratoren die Identität als Teil einer bestimmten Azure-Ressource, zum Beispiel einer VM. Diese Identität teilt einen Lebenszyklus mit ihrer zugehörigen Ressource. Das heißt, wenn Admins die Ressource löschen, löschen sie automatisch die Identität. Vom Benutzer zugewiesene Identitäten hingegen sind nicht an eine bestimmte Ressource gebunden. Sie haben ihren eigenen Lebenszyklus und lassen sich ressourcenübergreifend nutzen.
Der Hauptunterschied zwischen Azure Dienstprinzipalen und verwalteten Identitäten ist, dass Administratoren bei letzteren keine Anmeldeinformationen, einschließlich Passwörter, verwalten müssen.
Um eine verwaltete Identität zu erstellen, rufen Sie das Azure-Portal auf und navigieren Sie zur Ansicht für verwaltete Identitäten. Dann weisen Sie der Identität eine Rolle zu. Admins können manuell die Geltungsdauer für eine verwaltete Identität festlegen.
