Authentifizierung und Autorisierung in Microsoft Foundry

Die Authentifizierung und Autorisierung in Microsoft Foundry steuern, wie Prinzipale Identität nachweisen und die Berechtigung zum Ausführen von Vorgängen erhalten. Die Gießerei unterteilt Vorgänge in die Steuerungsebene (Ressourcenverwaltung) und die Datenebene (Laufzeitnutzung), die jeweils über eine eigene Authentifizierungs- und rollenbasierte Zugriffssteuerungsoberfläche (RBAC) verfügt.

Foundry unterstützt zwei Authentifizierungsmethoden: Microsoft Entra ID und API-Schlüssel. Microsoft Entra ID ermöglicht bedingten Zugriff, verwaltete Identitäten und granulare RBAC. API-Schlüssel bleiben für die schnelle Prototyperstellung verfügbar, aber es fehlt an der Rückverfolgbarkeit pro Benutzer. In diesem Artikel werden diese Methoden verglichen, Identitäten Rollen zugeordnet und allgemeine Szenarien mit den geringsten Berechtigungen beschrieben.

Voraussetzungen

• Ein Azure-Abonnement. Wenn Sie kein Konto haben, erstellen Sie ein kostenloses Konto.
• Eine Microsoft Foundry-Ressource mit konfigurierter benutzerdefinierter Unterdomäne .
• Grundlegendes zu Azure RBAC-Konzepten.
• Um Rollen zuzuweisen, benötigen Sie die Rolle " Besitzer" oder " Benutzerzugriffsadministrator " im entsprechenden Bereich.
• (Optional) Das Azure CLI - oder Azure SDK für Python ist für die programmgesteuerte Authentifizierung installiert.
• (Optional) Python-Pakete für Codebeispiele: pip install azure-identity requests

Steuerungsebene und Datenebene

Azure-Vorgänge teilen sich in zwei Kategorien auf: Steuerebene und Datenebene. Azure trennt die Ressourcenverwaltung (Kontrollebene) von der Betriebslaufzeit (Datenebene). Daher verwenden Sie die Steuerebene zum Verwalten von Ressourcen in Ihrem Abonnement und verwenden die Datenebene, um Funktionen zu verwenden, die von Ihrer Instanz eines Ressourcentyps verfügbar gemacht werden. Weitere Informationen zu Steuerungsebenen und Datenebenen finden Sie unter Azure-Steuerungsebene und -Datenebene. In Foundry gibt es einen klaren Unterschied zwischen Steuerungsebenenvorgängen und Datenebenenvorgängen. Die folgende Tabelle erläutert den Unterschied zwischen den beiden, den Umfang in Foundry, typische Vorgänge eines Benutzers, Beispieltools und Funktionen sowie die Autorisierungsoberfläche zur Nutzung jedes Teils.

Alle Bicep-, Terraform- und SDK-Beispiele finden Sie im Foundry-Samples-Repository auf GitHub für Foundry.

Die folgenden Listen und Diagramme veranschaulichen die Trennung zwischen Steuerungsebene und Datenebenenaktionen im Detail. Zu den Aktionen der Kontrollebene innerhalb von Foundry gehören:

• Erstellen von Foundry-Ressourcen
• Gießerei-Projekterstellung
• Erstellung eines Account Capability Hosts
• Erstellung von Project Capability Host
• Modellbereitstellung
• Konto- und Projektverbindungserstellung

Zu den Aktionen der Datenebene innerhalb von Foundry gehören:

• Erstellen von Agents
• Ausführen einer Auswertung
• Ablaufverfolgung und Überwachung
• Feinabstimmung

Das folgende Diagramm zeigt die Ansicht der Steuerungsebene im Vergleich zur Datenebenentrennung in Foundry zusammen mit rollenbasierten Zugriffssteuerungszuweisungen (RBAC) und dem Zugriff, über den ein Benutzer in der Steuerungsebene oder in der Datenebene oder in beidem verfügen könnte. Wie im Diagramm dargestellt, werden RBAC-"Aktionen" der Steuerungsebene zugeordnet, während RBAC "dataActions" mit der Datenebene verknüpft sind.

Authentifizierungsmethoden

Foundry unterstützt Microsoft Entra ID (tokenbasierte, schlüssellose) und API-Schlüssel.

Microsoft Entra ID

Microsoft Entra ID verwendet OAuth 2.0-Bearertoken, die auf https://ai.azure.com/.default festgelegt sind.

Verwenden Sie die Microsoft Entra-ID für:

• Produktionsbelastungen
• Bedingter Zugriff, mehrstufige Authentifizierung (MFA) und Just-in-Time-Zugriff.
• RBAC mit geringsten Rechten und Integration verwalteter Identitäten

Vorteile: Differenzierte Rollenzuweisungen, Prinzipalüberwachung, steuerbare Tokenlebensdauern, automatische Geheimnisschutzfunktionen und verwaltete Identitäten für Dienste.

Einschränkungen: Höhere Anfängliche Einrichtungskomplexität. Erfordert Kenntnisse der rollenbasierten Zugriffssteuerung (RBAC). Weitere Informationen zu RBAC in Foundry finden Sie unter Rollenbasierte Zugriffssteuerung für Microsoft Foundry.

API-Schlüssel

API-Schlüssel sind statische Geheimnisse, die auf eine Foundry-Ressource beschränkt sind.

Verwenden von API-Schlüsseln für:

• Schnelle Prototypisierung.
• Isolierte Testumgebungen, in denen die Rotation eines einzelnen Geheimnisses akzeptiert werden kann.

Vorteile: Einfach, sprachunabhängig und erfordert keine Tokenbeschaffung.

Einschränkungen: Die Benutzeridentität kann nicht ausgedrückt werden, ist schwer granular abzugrenzen und ist schwieriger zu prüfen. In der Regel nicht von unternehmensinternen Produktionsworkloads akzeptiert und nicht von Microsoft empfohlen.

Weitere Informationen zum Aktivieren der schlüssellosen Authentifizierung finden Sie unter Configure key-less authentication with Microsoft Entra ID.

Authentifizieren mit Microsoft Entra ID (Python)

Das folgende Beispiel zeigt, wie Sie sich mithilfe der azure-identity Bibliothek mit der Microsoft Entra-ID authentifizieren und eine Anforderung an einen Foundry-Endpunkt senden:

from azure.identity import DefaultAzureCredential
import requests

# Create a credential object using DefaultAzureCredential
# This automatically uses environment variables, managed identity, or Azure CLI credentials
credential = DefaultAzureCredential()

# Get an access token for the Cognitive Services scope
token = credential.get_token("https://ai.azure.com/.default")

# Use the token in your API request
headers = {
    "Authorization": f"Bearer {token.token}",
    "Content-Type": "application/json"
}

# Replace with your Foundry endpoint
endpoint = "https://<your-resource-name>.cognitiveservices.azure.com"

# Example: List deployments (adjust the path for your specific API)
response = requests.get(f"{endpoint}/openai/deployments?api-version=2024-10-21", headers=headers)
print(response.json())

Erwartete Ausgabe: Eine JSON-Antwort, die Ihre Modellbereitstellungen auflistet, oder ein Authentifizierungsfehler, wenn Anmeldeinformationen fehlen oder die Rollenzuweisung nicht konfiguriert ist.

Referenz: DefaultAzureCredential | Azure-Identity-Bibliothek

Authentifizieren mit einem API-Schlüssel (Python)

Das folgende Beispiel zeigt, wie Sie sich mithilfe eines API-Schlüssels authentifizieren. Verwenden Sie diesen Ansatz nur für schnelle Prototyperstellung; Microsoft Entra-ID wird für die Produktion empfohlen.

import requests

# Replace with your actual API key and endpoint
api_key = "<your-api-key>"
endpoint = "https://<your-resource-name>.cognitiveservices.azure.com"

headers = {
    "api-key": api_key,
    "Content-Type": "application/json"
}

# Example: List deployments
response = requests.get(f"{endpoint}/openai/deployments?api-version=2024-10-21", headers=headers)
print(response.json())

Erwartete Ausgabe: Eine JSON-Antwort, die Ihre Modellbereitstellungen auflistet, oder ein 401-Fehler, wenn der API-Schlüssel ungültig ist.

Referenz: Rotieren der API-Zugriffsschlüssel

Unterstützungsmatrix für Funktionen

Verweisen Sie auf die folgende Matrix, um zu verstehen, welche Funktionen im Foundry-Support-API-Schlüssel im Vergleich zur Microsoft Entra-ID vorhanden sind.

Identitätstypen

Azure-Ressourcen und -Anwendungen authentifizieren sich mithilfe verschiedener Identitätstypen, die jeweils für bestimmte Szenarien entwickelt wurden. Benutzerprinzipale stellen menschliche Benutzer dar, Dienstprinzipale stellen Anwendungen oder automatisierte Prozesse dar, und verwaltete Identitäten bieten eine sichere, anmeldeinformationsfreie Möglichkeit für Azure-Ressourcen, auf andere Dienste zuzugreifen. Wenn Sie diese Unterscheidungen verstehen, können Sie die richtige Identität für interaktive Anmeldungen, App-zu-App-Kommunikation oder Workloadautomatisierung auswählen.

Azure unterstützt die folgenden Identitätstypen.

Übersicht über integrierte Rollen

Verwenden Sie in Foundry die integrierten Rollen, um die zulässigen Aktionen für einen Benutzer zu trennen. Die meisten Unternehmen möchten eine Trennung von Steuerungs- und Datenebenenaktionen für ihre integrierten Rollen. Andere erwarten eine kombinierte Daten- und Steuerebenenrolle, um die Anzahl der erforderlichen Rollenzuweisungen zu minimieren. In der folgenden Tabelle sind Szenarien und die entsprechenden integrierten Foundry-Rollen aufgeführt, die für jedes Szenario am besten geeignet sind.

Um die Aufschlüsselung der integrierten Rollen und der Steuerungs- und Datenebenenaktionen zu verstehen, lesen Sie das folgende Diagramm.

Einrichten der Microsoft Entra-ID

Eine allgemeine Anleitung zum Einrichten der Entra-ID-Authentifizierung in Foundry finden Sie unter Konfigurieren der Authentifizierung ohne Schlüssel.

1. Stellen Sie sicher, dass Ihre Microsoft Foundry-Ressource eine benutzerdefinierte Unterdomäne konfiguriert hat. Siehe benutzerdefinierte Unterdomänen. Für die tokenbasierte Authentifizierung ist eine benutzerdefinierte Unterdomäne erforderlich.

2. Weisen Sie jedem Prinzipal die notwendige integrierte oder benutzerdefinierte Rolle zu. Sie benötigen die Rolle "Besitzer" oder " Benutzerzugriffsadministrator " im Zielbereich, um Rollen zuzuweisen. Allgemeine Rollenzuweisungen:

   • Foundry User: Für Entwickler, die mit vorab bereitgestellten Modellen entwickeln und testen müssen.
   • Foundry Project Manager: Für Teamleiter, die Projekte erstellen und Bereitstellungen verwalten müssen.
   • Foundry-Kontobesitzer: Für Administratoren, die eine vollständige Ressourcenverwaltung benötigen und unter bestimmten Bedingungen die Rolle „Foundry User“ für den Zugriff auf die Datenebene zuweisen können.
   • Gießereibesitzer: Für Benutzer, die sowohl vollständigen Ressourcenverwaltungs- als auch Datenebenenzugriff benötigen. Beispiel-CLI-Befehl zum Zuweisen der Rolle "Foundry User":

   az role assignment create \
     --assignee <principal-id> \
     --role "53ca6127-db72-4b80-b1b0-d745d6d5456d" \
     --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<resource-name>
   

Um die Rollenzuweisung zu überprüfen, führen Sie az role assignment list --assignee <principal-id> --scope <resource-scope> aus und bestätigen Sie, dass die Rolle in der Ausgabe erscheint.

1. (Optional) Erstellen Sie für einen Dienstprinzipal eine App-Registrierung, fügen Sie einen geheimen Clientschlüssel oder ein Zertifikat hinzu, und notieren Sie sich die Mandanten-ID, die Client-ID und den geheimen Schlüssel oder das Zertifikat.
2. (Optional) Aktivieren Sie für eine verwaltete Identität die vom System zugewiesene Identität für den aufrufenden Dienst, oder fügen Sie eine vom Benutzer zugewiesene Identität an, und weisen Sie ihr dann eine Rolle in der Foundry-Ressource zu.
3. Entfernen Sie die schlüsselbasierte Authentifizierung, nachdem alle Aufrufer die Tokenauthentifizierung verwenden. Deaktivieren Sie optional die lokale Authentifizierung in Bereitstellungsvorlagen.

Referenz: Azure-Rollen zuweisen | Rollenbasierte Zugriffssteuerung für Gießerei

Fehlerbehebung bei häufigen Authentifizierungsfehlern

Verwandte Inhalte

• Rollenbasierte Zugriffssteuerung für Foundry
• Konfigurieren der Authentifizierung ohne Schlüssel mit Microsoft Entra-ID
• Wechseln von API-Zugriffsschlüsseln
• Integrierte Azure-Rollen (KI + maschinelles Lernen)
• Authentifizierung im Vergleich zur Autorisierung (Microsoft Entra-ID)
• Grundlagen der Identität