Verwaltete Identitäten in Microsoft Discovery

Microsoft Discovery verwendet vom Benutzer zugewiesene verwaltete Identitäten (UAMIs), um sich bei Azure Ressourcen in Ihrem Auftrag zu authentifizieren. Anstatt geheime Schlüssel oder Verbindungszeichenfolgen zu verwalten, erstellen Sie eine verwaltete Identität, erteilen sie die erforderlichen Azure Rollen und stellen ihre Ressourcen-ID bereit, wenn Sie Discovery-Ressourcen erstellen. Die Discovery-Plattform verwendet diese Identität dann, um auf Speicherkonten, Containerregistrierungen, KI-Dienste und Ressourcen der verwalteten Ressourcengruppe (Managed Resource Group, MRG) zuzugreifen.

Warum vom Benutzer zugewiesene verwaltete Identitäten

Die Ermittlung erfordert aus den folgenden Gründen vom Benutzer zugewiesene (nicht vom System zugewiesene) verwaltete Identitäten:

Grund Explanation
Eigentum des Kunden Sie erstellen, verwalten und steuern den Lebenszyklus der Identität in Ihrem eigenen Abonnement.
Gemeinsame Nutzung über Ressourcen hinweg Sie können ein einzelnes UAMI in einem Arbeitsbereich, Supercomputer und Speichervorgängen wiederverwenden, wodurch der Verwaltungsaufwand reduziert wird.
Elektronisch bereitgestellte Rollenzuweisungen Sie weisen Rollen vor der Ressourcenerstellung zu, sodass Discovery über die berechtigungen verfügt, die sie von Anfang an benötigt.
Unveränderliche Bindung Die Arbeitsbereichsidentität und die Clusteridentität des Supercomputers sind zur Erstellungszeit gebunden und können später nicht geändert werden, wodurch ein konsistenter Sicherheitsstatus sichergestellt wird. Sie können die Kubelet- und Workloadidentitäten des Supercomputers nach der Erstellung aktualisieren.

Von Bedeutung

Die Arbeitsbereichsidentität und die Clusteridentität des Supercomputers sind nach der Erstellung unveränderlich . Sie können sie nach der Bereitstellung nicht mehr ändern. Sie können die Kubelet- und Workloadidentitäten des Supercomputers aktualisieren. Planen Sie Ihre Identitätsstrategie, bevor Sie Ressourcen erstellen.

Wie Discovery Ihre Identität verwendet

Wenn ein Arbeitsbereich oder Supercomputer erstellt wird, führt die Discovery-Steuerungsebene Folgendes durch:

  • Liest Ihre UAMI: Überprüft, ob die Identität vorhanden ist und dass der Dienst damit arbeiten kann.
  • Sie weist sich selbst als Operator für verwaltete Identität zu: Der Discovery-Dienstprinzipal erhält die Rolle „Operator für verwaltete Identität“ für Ihre UAMI, um die Identität für verwaltete Ressourcenvorgänge zu verwenden.
  • Verwendet die UAMI zur Laufzeit: Auf dem Supercomputer ausgeführte Tool-Ausführungen verwenden diese Identität, um Containerimages abzurufen und auf Blobspeicher zuzugreifen. Agents verwenden sie, um mit Azure OpenAI und Speicher zu interagieren.

Identitätsslots pro Ressourcentyp

Verschiedene Discoveryressourcen verwenden verwaltete Identitäten auf unterschiedliche Weise.

Workspace

Ein Arbeitsbereich benötigt eine einzelne UAMI, die über die Eigenschaft workspaceIdentity bereitgestellt wird. Discovery verwendet Ihr UAMI für Folgendes:

  • Identifizieren Sie Ihren Arbeitsbereich: UAMI ist der Sicherheitsprinzipal, der den Arbeitsbereich an die Ressourcen Ihres Abonnements bindet.
  • Daten lesen und schreiben: Azure Blob Storage-Konten lesen und schreiben Daten über Speichercontainer.
  • Pullcontainerimages: Containerimages werden von Azure Container Registry abgerufen, wenn Sie Tools auf einem Supercomputer ausführen.

Discovery stellt die MRG (Azure Cosmos DB, KI-Dienste, Suchindizes und Azure OpenAI) unter Verwendung eigener Dienstprinzipale bereit und betreibt sie, nicht Ihre UAMI. Ihre UAMI benötigt keine Rollen in der MRG.

Supercomputer

Ein Supercomputer verwendet drei Identitätsslots, die der Einfachheit halber alle auf dieselbe UAMI oder nach dem Least-Privilege-Prinzip auf separate UAMIs verweisen können.

Schlitz Purpose
Clusteridentität Wird von der AKS-Steuerungsebene verwendet, um Ressourcen auf Clusterebene wie Netzwerk- und Lastenausgleich zu verwalten.
Kubelet-Identität Wird auf Knotenebene verwendet, um Containerimages aus der Containerregistrierung abzurufen und auf Azure Ressourcen zuzugreifen.
Workload-Identität Verwendet als Verbundanmeldeinformationen von Pods, die Tools und Agents auf dem Supercomputer ausführen.

Bücherregal

Ein Bookshelf verweist über die Eigenschaft workloadIdentities auf Ihre UAMI. Erkennung verwendet eigene Dienstprinzipale zum Bereitstellen und Betreiben des Bookshelf MRG (AI Search, SQL, AI Services). Der Dienst erstellt außerdem eine vom System verwaltete Identität innerhalb der Bookshelf-MRG für die interne Authentifizierung zwischen Ressourcen.

Erforderliche Rollenzuweisungen

Sie müssen Ihrer UAMI die folgenden integrierten Rollen zuweisen, bevor Sie Discovery-Ressourcen erstellen. Weisen Sie diese Rollen auf der Ebene der Ressourcengruppe zu.

Rolle Rollendefinitions-ID Purpose
Microsoft Discovery Platform-Mitwirkender (Vorschau) 01288891-85ee-45a7-b367-9db3b752fc65 Verwalten Sie Discoveryressourcen, z. B. Arbeitsbereiche, Projekte, Agents und Tools.
Storage Blob-Datenmitwirkender ba92f5b4-2d11-453d-a403-e96b0029c9fe Lesen und Schreiben von Blobs in Azure Storage-Konten.
AcrPull 7f951dda-4ed3-4680-a7ca-43fe172d538d Container-Bilder aus der Container-Registry abrufen.

Weitere Rollen, die in speziellen Szenarien benötigt werden, finden Sie unter Konfigurieren verwalteter Identitäten.

End-to-End-Identitätsfluss über Discovery-Ressourcen hinweg

Wenn Sie einen vollständigen Discovery-Stapel bereitstellen, erstellt die Plattform drei MRGs (Arbeitsbereich, Bücherhelf und Supercomputer). Jede MRG enthält Azure Ressourcen, die der Dienst verwaltet.

Was der Dienst automatisch verwaltet

Wenn Sie einen Arbeitsbereich, ein Bücherregal oder einen Supercomputer erstellen, führt Discovery automatisch Folgendes aus:

  • Erstellt Rollenzuweisungen auf der MRG, sodass der Dienst MRG-Ressourcen bereitstellen und betreiben kann. Die Ressourcen umfassen Microsoft Foundry, Azure Cosmos DB, Azure KI-Suche, Storage, Azure Key Vault und Azure Kubernetes Service (AKS).
  • Weist Ihrer UAMI einen Operator für verwaltete Identität zu, damit der Dienst diesen für MRG-Bereitstellungen verwenden kann.
  • Erstellt eine vom System verwaltete Identität innerhalb der einzelnen Arbeitsbereiche und der Bookshelf-MRG für die interne Authentifizierung zwischen Ressourcen (Azure Container Apps, Foundry, SQL).

Sie müssen keine dieser Identitäten oder Rollenzuweisungen erstellen oder verwalten. Sie werden über ihren gesamten Lebenszyklus hinweg vom Dienst verwaltet.

Für was Sie verantwortlich sind

Sie sind für die folgenden Aufgaben verantwortlich:

  • Erstellen Sie Ihre UAMI: Weisen Sie die drei Kernrollen (Discovery Platform Contributor, Storage Blob Data Contributor und AcrPull) zu, bevor Sie Discovery-Ressourcen erstellen.
  • Geben Sie die UAMI-Ressourcen-ID an: Geben Sie die ID ein, wenn Sie einen Arbeitsbereich oder Supercomputer erstellen.

Ihr UAMI zur Laufzeit

Ihre UAMI ist die Identität, die Agenten und Tools zur Laufzeit verwenden.

Operation zugriff auf Azure Ressource Erforderliche Rolle
Lese-/Schreibzugriff auf Daten in Speichercontainern Azure Blob Storage Storage Blob-Datenmitwirkender
Containerimages für Pulltools Container Registry AcrPull
Verwalten von Discoveryressourcen Anbieter von Suchressourcen Microsoft Discovery Platform-Mitwirkender (Vorschau)
Betreiben von AKS-Clusternetzwerken Azure Virtual Network (VNet)-Subnetze Netzwerkmitwirkender (Supercomputerclusteridentität)

Für den Supercomputer wird Ihr UAMI in drei Steckplätzen verwendet:

  • Clusteridentität: Die AKS-Steuerungsebene verwendet sie zum Verwalten von Load Balancern und Netzwerkfunktionen.
  • Kubelet-Identität: Der Agent auf Knotenebene verwendet ihn, um Bilder aus der Containerregistrierung abzurufen und auf Azure Ressourcen zuzugreifen.
  • Workload-Identität: Pods verwenden Verbundanmeldeinformationen zum Ausführen von Tools und Agents.

Anleitungen zur Auswahl zwischen einem einzelnen freigegebenen UAMI und separaten Identitäten pro Funktion finden Sie unter Empfehlungen zu bewährten Methoden für verwaltete Identitäten.

Erweiterte Konfiguration: Granulare Rollenzuweisungen je Identität

Der Abschnitt "Erforderliche Rollenzuweisungen " beschreibt den einfachsten Ansatz, bei dem ein einzelnes freigegebenes UAMI alle drei Kernrollen im Ressourcengruppenbereich empfängt. Weisen Sie für Produktionsumgebungen, die strengere Sicherheitskontrollen erfordern, separate UAMIs mit Rollenzuweisungen nach dem Least-Privilege-Prinzip zu, die auf die spezifischen Ressourcen beschränkt sind, auf die die jeweilige Identität zugreift.

Von Bedeutung

Auf die Workloadidentität kann durch Agenten über die Ausführung von Tools zugegriffen werden. Agents, die von großsprachigen Modellen (LLMs) gesteuert werden, rufen Tools auf, die diese Identität zur Laufzeit verwenden, sodass die Minimierung der Berechtigungen der Workloadidentität von entscheidender Bedeutung ist. Weisen Sie nur die für Toolvorgänge unbedingt erforderlichen Berechtigungen zu. Weitreichende Berechtigungen für die Workload-Identität stellen ein Risiko dar, wenn ein Agent die Identität über ihren vorgesehenen Umfang hinaus verwendet.

Rollenzuweisungen pro Identität

Die folgende Tabelle zeigt die empfohlene granulare Rollenzuweisung für jede Identität, wenn Sie separate UAMIs verwenden.

Identity Rolle Geltungsbereich Purpose
Arbeitsbereichsidentität Microsoft Discovery Platform-Mitwirkender (Vorschau) Ressourcengruppe Verwalten Sie Ressourcen des Arbeitsbereichs wie Projekte, Bereitstellungen von Chatmodellen und Speichercontainer.
Arbeitsbereichsidentität Storage Blob-Datenmitwirkender Speicherkonto Lese-/Schreibzugriff auf Arbeitsbereichsdaten, Chatmodellartefakte und Projektressourcen im Sicherungsspeicherkonto.
Clusteridentität Plattformverwalteter Netzwerkmitwirkender Knotenressourcengruppe/VNet Verwalten von Netzwerken auf Clusterebene, Lastenausgleichsmodulen und Ressourcen der Knotenressourcengruppe.
Clusteridentität Operator für verwaltete Identität Knotenressourcengruppe Verwaltete Identitäten von Clusterworkloads verwalten.
Kubelet-Identität AcrPull Ressourcengruppe (umfasst Containerregistrierung) Containerimages für Toolausführungen aus jeder in der Ressourcengruppe bereitgestellten Container Registry abrufen.
Kubelet-Identität Storage Blob-Datenmitwirkender Speicherkonto Lesen von Workload-Artefakten und Inputs aus dem Backing-Storage-Konto beim Start des Pods.
Workload-Identität Storage Blob-Datenmitwirkender Speicherkonto Greifen Sie während der Toolausführung durch Agentworkloads (föderierte Identität) auf Daten zu.

Warum separate Identitäten die Sicherheit verbessern

Wenn Sie eine einzige gemeinsam genutzte UAMI verwenden, erhält die Workload-Identität, die Agents bei der Ausführung von Tools verwenden, alle Rollen, einschließlich Discovery Platform-Mitwirkender und AcrPull. Dadurch erhalten LLM-gesteuerte Agents einen breiteren Zugriff als sie benötigen.

Durch Trennen von Identitäten:

  • Die Workloadidentität erhält auf Ebene des Speicherkontos lediglich die Rolle „Mitwirkender an Storage-Blobdaten“, wodurch der Zugriff der Agenten über Tools eingeschränkt ist.
  • Die Clusteridentität empfängt Netzwerk- und Operatorrollen, die niemals Agent-Workloads offengelegt werden.
  • Die Kubelet-Identität übernimmt Image-Abrufe und den Zugriff auf Pod-Startdaten, getrennt von der Ausführung des Agent-Tools.

Diese Trennung stellt sicher, dass die Anforderung aufgrund unzureichender Berechtigungen fehlschlägt, auch wenn ein Agent versucht, seine Identität für Vorgänge außerhalb des Datenzugriffs zu verwenden.

Wann präzise Zuordnungen verwendet werden sollen

Verwenden Sie separate Identitäten mit bereichsbezogenen Rollen, wenn:

  • Für Ihre Organisation ist die Zugriffssteuerung mit geringsten Berechtigungen erforderlich.
  • Sie führen Tools aus, die vertrauliche Daten verarbeiten, und möchten den Schadensradius begrenzen.
  • Ihre Complianceanforderungen erfordern die Trennung von Identitäten zwischen Steuerebenen und Datenebenen.
  • Sie möchten den Agentdatenzugriff unabhängig von Infrastrukturvorgängen überwachen.

Hinweise zur Auswahl zwischen gemeinsamen und getrennten Identitäten finden Sie unter Empfehlungen zu bewährten Methoden für verwaltete Identitäten.

Einschränkungen

  • Das UAMI muss sich in derselben Region wie die Discovery-Ressource befinden, die sie verwendet.
  • Die Arbeitsbereichsidentität und die Clusteridentität des Supercomputers können nach der Ressourcenerstellung nicht mehr geändert werden. Sie müssen die Ressource löschen und erneut erstellen. Sie können die Kubelet- und Workloadidentitäten des Supercomputers über PATCH aktualisieren.
  • Die Rollenzuweisungsverteilung kann bis zu 10 Minuten dauern. Erstellen Sie Rollenzuweisungen, bevor Sie Discoveryressourcen erstellen.
  • Der Erkennungs-Dienst benötigt eine Rolle „Operator für verwaltete Identität“ für Ihre UAMI. Wenn diese Rollenzuweisung während der Ressourcenerstellung fehlschlägt (z. B. aufgrund von Azure Policy Einschränkungen), schlägt die Arbeitsbereichsbereitstellung fehl.