Table of contents

Einführung

Es gibt einige Möglichkeiten sich in Azure zu authentifizieren aus einem Service. Dafür gibt es nicht diesen einen Weg, sondern es gibt verschiedene Wege. Und nicht nur, dass es grundsätzlich unterschiedliche Wege gibt, sondern auch mehrere Wege gleichzeitig sind technisch möglich, haben aber alle Vor und Nachteile. Im folgenden Artikel sollen die aktuellen Möglichkeiten dargestellt und gegenübergestellt werden.

System-assigned Managed Identity

Die System-assigned Managed Identity ist eine native Funktion in Azure um Services eine Identität zu geben in der sie auf andere Ressourcen zugreifen kann. In der Regel muss die System-assigned Managed Identity aktiviert werden, das erstellt eine Enterprise App im Entra ID. Diese System-assigned Managed Identity kann nun auf anderen Ressourcen berechtigt werden. Das Service mit der aktivierten System-assigned Managed Identity verwendet diese Identität in der Regel automatisch oder ist einfach anzuweisen, die zugeordnete Identität zu verwenden.

Vorteile:

• Die Nutzung der Managed Identity ist in Azure vollständig integriert
• Es gibt keine ablaufenden Secrets oder andere Aktualisierungen die notwendig sein
• Der Abbau-Prozess ist ebenso vollständig berücksichtigt (wird die Azure Ressource mit aktivierter Managed Identity gelöscht, wird auch die dazugehörige Enterprise App im Entra ID gelöscht)

User-assigned Managed Identity

Es ist möglich im Azure ein eigenes Objekt zu erstellen und dann eine App dafür zu verwenden. Im wesentlichen agiert diese User-assigned Managed Identity wie die Managed Identity ist also sehr praktisch und funktioniert aber nur für bestimmte Azure Services. Warum möchte man also eine User-assigned Managed Identity haben:

• Mehrere Azure Services sollen mit einer Identität agieren
• Decoupiling zwischen Azure Service und der Identität (für bestimmte Szenarien, oder Tests kann es praktisch sein)

Der Nachteil:

• Das erzeugte Objekte in Azure muss, wenn es nicht mehr benötigt wird, gelöscht werden. (Zur Erinnerung, bei einer System-assigned Managed Identity wird die Identity (im Entra ID) direkt gelöscht wenn die Ressource gelöscht wird)

App Registration (Federated credentials)

In einer App Registration im Entra ID ist es möglich federated credentials zu konfigurieren. Eine Übersicht der Funktionsweise findet sich in dieser Beschreibung: Overview of federated identity credentials in Microsoft Entra ID. Dabei wird ein ganz wesentlicher Vorteil beschrieben: Es gibt keine Secrets mehr zu managen und daher auch keine Secrets mehr die ablaufen können. Besonders im operativen Bereich, sorgt das für wesentlich mehr Stabilität. Allerdings gibt es Limitierungen, wie auch in dem Artikel Add and manage application credentials in Microsoft Entra ID nachzulesen ist. Es werden folgende Systeme unterstützt:

• Customer managed keys
• GitHub actions deploying Azure resources
• Kubernetes accessing Azure resources
• Other issuer

App Registration (Client secrets and Certificates)

In einer App Registration gibt es neben federated credentials auch die Möglichkeit Client Secrets oder Zertifikate zu verwenden. Der Nachteil an dieser Methode ist, dass ich ein Secret (also entweder ein String (im Falle von Client secrets) oder ein Zertifikat) managen muss. Auch können diese Secrets nicht ewig leben - Entra hat hier eine maximale Lebensdauer (aus guten sicherheitstechnischen Gründen). Aber diese Lifecycle Thematik bringt Wartungsaufwand mit sich und muss im laufenden Betriebs berücksichtigt werden, läuft ein Secret ab kann die Applikation sich nicht mehr authentifizieren und wird in der Funktion zumindestens eingeschränkt sein.

Zusammenfassung

Zusammenfassend alle möglichen Methoden gelistet nach dem präferierten Weg (niedrigere Zahl ist besser)