Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
L’authentification et l’autorisation dans Microsoft Foundry contrôlent la façon dont les principaux prouvent l’identité et obtiennent l’autorisation d’effectuer des opérations. Foundry divise les opérations en plan de contrôle (gestion des ressources) et en plan de données (utilisation du runtime), chacun avec sa propre surface d’authentification et de contrôle d’accès en fonction du rôle (RBAC).
Foundry prend en charge deux méthodes d’authentification : l’ID Microsoft Entra et les clés API. Microsoft Entra ID permet l’accès conditionnel, les identités managées et le RBAC granulaire. Les clés API restent disponibles pour le prototypage rapide, mais manquent de traçabilité par utilisateur. Cet article compare ces méthodes, mappe les identités aux rôles et décrit les scénarios courants de privilèges minimum.
Important
Utilisez Microsoft Entra ID pour les charges de travail en production afin d’activer l’accès conditionnel, les identités managées et le RBAC avec privilèges minimum. Les clés API sont pratiques pour une évaluation rapide, mais fournissent un accès à granularité grossière.
Conditions préalables
- Un abonnement Azure. Si vous n’en avez pas, créez un compte gratuit.
- Ressource Microsoft Foundry avec un sous-domaine personnalisé configuré.
- Compréhension des concepts RBAC Azure.
- Pour attribuer des rôles, vous avez besoin du rôle Propriétaire ou du rôle Administrateur de l’accès utilisateur au niveau de l’étendue appropriée.
- (Facultatif) Azure CLI ou Kit de développement logiciel (SDK) Azure pour Python installé pour l’authentification par programmation.
- (Facultatif) Packages Python pour les exemples de code :
pip install azure-identity requests
Plan de contrôle et plan de données
Les opérations Azure se divisent en deux catégories : plan de contrôle et plan de données. Azure sépare la gestion des ressources (plan de contrôle) du runtime opérationnel (plan de données). Par conséquent, vous utilisez le plan de contrôle pour gérer les ressources de votre abonnement et utilisez le plan de données pour utiliser les fonctionnalités exposées par votre instance d’un type de ressource. Pour en savoir plus sur le plan de contrôle et le plan de données, consultez le plan de contrôle Azure et le plan de données. Dans Foundry, il existe une distinction claire entre les opérations de plan de contrôle et les opérations de plan de données. Le tableau suivant explique la différence entre les deux, l’étendue dans Foundry, les opérations classiques d’un utilisateur, les exemples d’outils et de fonctionnalités et la surface d’autorisation à utiliser.
| Avion | Étendue dans Foundry | Opérations classiques | Exemples d’outils | Surface d’autorisation |
|---|---|---|---|---|
| Plan de contrôle | Mise en place et configuration des ressources, projets, réseaux, chiffrement et connexions | Créer ou supprimer des ressources, attribuer des rôles, faire pivoter des clés, configurer Private Link | Portail Azure, Azure CLI, modèles ARM, Bicep, Terraform | Actions RBAC Azure |
| Plan de données | Exécution et utilisation de l’inférence de modèles, des interactions des agents, des tâches d’évaluation et des appels relatifs à la sécurité du contenu | Achèvement de la conversation, génération d'intégration, démarrage des travaux d'ajustement fin, envoi de messages d'un agent, opérations d'analyseur et de classification | Kit de développement SDK, API REST, bac à sable du portail Foundry | dataActions RBAC Azure |
Pour tous les exemples Bicep, Terraform et SDK, consultez le dépôt foundry-samples sur GitHub pour Foundry.
Les listes et diagrammes suivants illustrent la séparation entre les actions du plan de contrôle et du plan de données en détail. Les actions du control plane dans Foundry sont les suivantes :
- Création de ressources de Foundry
- Création de projet Foundry
- Création de l’hôte de capacité de compte
- Création d’un hôte de fonctionnalité de projet
- Déploiement de modèle
- Création de la connexion entre un compte et un projet
Les actions de plan de données dans Foundry sont les suivantes :
- Création d’agents
- Exécution d’une évaluation
- Suivi et surveillance
- Réglage précis
Le diagramme suivant montre la vue du plan de contrôle par rapport à la séparation du plan de données dans Foundry en même temps que les attributions de contrôle d’accès en fonction du rôle (RBAC) et l’accès qu’un utilisateur peut avoir dans le plan de contrôle ou le plan de données ou les deux. Comme indiqué dans le diagramme, les « actions » RBAC sont associées au plan de contrôle, tandis que les « dataActions » RBAC sont associées au plan de données.
Méthodes d’authentification
Foundry prend en charge l’ID Microsoft Entra (basé sur des jetons, sans clé) et les clés API.
Microsoft Entra ID
Microsoft Entra ID utilise des jetons du porteur OAuth 2.0 limités à https://ai.azure.com/.default.
Utilisez l’ID Microsoft Entra pour :
- Charges de travail de production.
- Accès conditionnel, authentification multifacteur (MFA) et accès juste-à-temps.
- Intégration du RBAC à moindre privilège et de l’identité managée.
Avantages : affectations de rôles précises, audit par principal, durées de vie des jetons contrôlables, hygiène secrète automatique et identités managées pour les services.
Limitations : complexité de configuration initiale plus élevée. Nécessite une compréhension du contrôle d’accès en fonction du rôle (RBAC). Pour plus d’informations sur RBAC dans Foundry, consultez contrôle d’accès en fonction du rôle pour Microsoft Foundry.
Clés API
Les clés API sont des secrets statiques délimités à une ressource Foundry.
Utilisez des clés API pour :
- Prototypage rapide.
- Environnements de test isolés où la rotation à secret unique est acceptable.
Avantages : simple, indépendant du langage et ne nécessite pas d’acquisition de jetons.
Limitations : Impossible d’exprimer l’identité de l’utilisateur, est difficile à étendre de manière granulaire et est plus difficile à auditer. Généralement non accepté par les charges de travail de production d’entreprise et non recommandés par Microsoft.
Pour plus d’informations sur l’activation de l’authentification sans clé, consultez Configurer l’authentification sans clé avec l’ID Microsoft Entra.
S’authentifier avec Microsoft Entra ID (Python)
L’exemple suivant montre comment s’authentifier avec l’ID Microsoft Entra à l’aide de la azure-identity bibliothèque et effectuer une demande à un point de terminaison Foundry :
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())
Sortie attendue : une réponse JSON répertoriant vos déploiements de modèle ou une erreur d’authentification si les informations d’identification sont manquantes ou si l’attribution de rôle n’est pas configurée.
Référence : DefaultAzureCredential | bibliothèque azure-identity
S’authentifier avec une clé API (Python)
L’exemple suivant montre comment s’authentifier à l’aide d’une clé API. Utilisez cette approche pour le prototypage rapide uniquement ; L’ID Microsoft Entra est recommandé pour la production.
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())
Avertissement
Les clés API fournissent un accès complet à la ressource et ne peuvent pas être étendues à des utilisateurs ou actions spécifiques. Faites régulièrement pivoter les clés et évitez de les valider dans le contrôle de source.
Sortie attendue : une réponse JSON répertoriant vos déploiements de modèle ou une erreur 401 si la clé API n’est pas valide.
Référence : faire pivoter les clés d’accès d’API
Matrice de prise en charge des fonctionnalités
Consultez la matrice suivante pour comprendre les fonctionnalités dans Foundry prenant en charge la clé API par rapport à Microsoft Entra ID.
| Capacité ou fonctionnalité | Clé API | Microsoft Entra ID | Notes |
|---|---|---|---|
| Inférence de modèle de base (conversation, incorporations) | Oui | Oui | Entièrement pris en charge. |
| Opérations de réglage précis | Oui | Oui | Entra ID ajoute un audit par principal. |
| Service des agents | Non | Oui | Utilisez l’ID Entra pour l’accès aux outils d’identité managée. |
| Évaluations | Non | Oui | Utilisez l’ID Entra. |
| Analyse de la sécurité du contenu des appels | Oui | Oui | Utilisez RBAC pour limiter les opérations à haut risque. |
| Travaux d’analyse par lots (Content Understanding) | Oui | Oui | Entra ID recommandé pour l'extension des capacités. |
| Utilisation du terrain de jeu du portail | Oui | Oui | Playground utilise le mode de connexion de projet. |
| Isolation réseau avec liaison privée | Oui | Oui | Entra ID ajoute l’accès conditionnel. |
| Privilège minimum avec des rôles intégrés et personnalisés | Non | Oui | Les clés sont tout ou rien pour chaque ressource. |
| Identité managée (système ou affectée par l’utilisateur) | Non | Oui | Permet l’authentification sans secret. |
| Attribution de l’utilisateur par demande | Non | Oui | Le jeton contient des ID de locataire et d’objet. |
| Révocation (immédiate) | Tourner la clé | Supprimer le rôle ou désactiver l'entité principale | La courte durée de vie du jeton s'applique. |
| Assistance pour les pipelines d’automatisation | Oui (secret) | Oui (principal de service ou identité managée) | Entra ID réduit la rotation des secrets. |
| API des Assistants | Oui | Oui | Recommandé d’utiliser l’ID Entra. |
| Inférence par lots | Oui | Oui | |
| Boîte à outils | Non | Oui | Utilisez l’ID Entra pour l’accès aux outils d’identité managée. |
Types d’identités
Les ressources et applications Azure s’authentifient à l’aide de différents types d’identité, chacun conçu pour des scénarios spécifiques. Les principaux d’utilisateur représentent des utilisateurs humains, les principaux de service représentent des applications ou des processus automatisés, et les identités managées fournissent un moyen sécurisé et sans informations d’identification pour les ressources Azure d’accéder à d’autres services. La compréhension de ces distinctions vous aide à choisir l’identité appropriée pour les connexions interactives, la communication d’application à application ou l’automatisation de la charge de travail.
Azure prend en charge les types d’identité suivants.
| Type d’identité | Description |
|---|---|
| Utilisateur principal | Utilisateur individuel dans Microsoft Entra ID |
| Principal de service (inscription d’application) | Identité d’application qui utilise une clé secrète client ou un certificat |
| Identité managée (affectée par le système) | Identité liée aux ressources Azure gérée automatiquement par la plateforme. |
| Identité managée (affectée par l’utilisateur) | Identité autonome qui s’attache à plusieurs ressources. |
Vue d’ensemble des rôles intégrés
Dans Foundry, utilisez les rôles intégrés pour séparer les actions autorisées pour un utilisateur. La plupart des entreprises souhaitent séparer les actions de contrôle et de plan de données pour leurs rôles intégrés. D’autres s’attendent à ce qu’un rôle de plan de contrôle et de données combiné réduise le nombre d’attributions de rôles requises. Le tableau suivant répertorie les scénarios et les rôles intégrés de Foundry qui conviennent le mieux à chaque scénario.
| Scénario | Rôles intégrés classiques | Notes |
|---|---|---|
| Générer des agents avec des modèles prédéployés | Utilisateur de Foundry | Utilisation du plan de données uniquement ; aucune écriture de gestion. |
| Gérer les déploiements ou ajuster les modèles | Gestionnaire de projet Foundry | Inclut la création et la mise à jour du déploiement de modèle. |
| Faire pivoter des clés ou gérer une ressource | Propriétaire du compte Foundry | Privilège élevé ; envisagez un rôle personnalisé pour le moindre privilège. |
| Administrez les ressources, gérez les déploiements et créez des agents. | Propriétaire de la fonderie | Rôle libre-service hautement privilégié pour les utilisateurs qui ont besoin à la fois d’un plan de contrôle et d’un accès au plan de données. Combinez-le avec le lecteur Azure Monitor si l’observabilité est requise. |
| Observabilité, suivi, surveillance | Utilisateur Foundry (minimum) | Ajoutez le lecteur Azure Monitor sur Application Insights. |
Important
Les rôles Foundry RBAC ont été récemment renommés. Foundry User, Foundry Owner, Propriétaire du compteFoundry et Foundry Project Manager ont été précédemment nommés Azure utilisateur IA, Azure propriétaire d’IA, propriétaire Azure compte IA et Azure gestionnaire Project IA. Il se peut que vous voyiez encore les anciens noms à certains endroits pendant le déploiement de ce changement de nom. Les ID de rôle et les autorisations de base ne sont pas modifiés par ce changement de nom.
Pour comprendre la répartition des rôles intégrés et des actions de contrôle et de plan de données, passez en revue le diagramme suivant.
Conseil
Créez un rôle personnalisé si un rôle intégré accorde des autorisations excédentaires pour votre cas d’usage.
Configurer l’ID Microsoft Entra
Pour obtenir des conseils généraux sur la configuration de l’authentification Entra ID dans Foundry, consultez Configurer l’authentification sans clé.
Vérifiez que votre ressource Microsoft Foundry a un sous-domaine personnalisé configuré. Consultez les sous-domaines personnalisés. Un sous-domaine personnalisé est requis pour l’authentification basée sur les jetons.
Attribuez le rôle intégré ou personnalisé nécessaire à chaque principal. Vous avez besoin du rôle Propriétaire ou Administrateur de l’accès utilisateur dans l’étendue cible pour attribuer des rôles. Attributions de rôles courantes :
- Utilisateur Foundry : pour les développeurs qui doivent générer et tester avec des modèles prédéployés.
- Foundry Project Manager : pour les responsables d’équipe qui doivent créer des projets et gérer des déploiements.
- Propriétaire du compte Foundry : pour les administrateurs qui ont besoin d’une gestion complète des ressources et peuvent affecter conditionnellement l’utilisateur Foundry pour l’accès au plan de données.
- Propriétaire de Foundry : pour les utilisateurs qui ont besoin d’un accès complet à la gestion des ressources et au plan de données. Exemple de commande CLI pour attribuer le rôle d’utilisateur Foundry :
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>
Note
Étant donné que les rôles RBAC Foundry ont été récemment renommés, utilisez l’ID de définition de rôle (GUID) au lieu du nom de rôle dans votre code pour éviter les problèmes lors du lancement du renommage :
-
Utilisateur Foundry :
53ca6127-db72-4b80-b1b0-d745d6d5456d -
Propriétaire de Foundry :
c883944f-8b7b-4483-af10-35834be79c4a -
Propriétaire du compte Foundry :
e47c6f54-e4a2-4754-9501-8e0985b135e1 -
Foundry Project Manager :
eadc314b-1a2d-4efa-be10-5d325db5065e
Pour vérifier l’attribution de rôle, exécutez az role assignment list --assignee <principal-id> --scope <resource-scope> et confirmez que le rôle apparaît dans la sortie.
- (Facultatif) Pour un principal de service, créez une inscription d’application, ajoutez un secret client ou un certificat, puis notez l’ID du locataire, l’ID client et le secret ou le certificat.
- (Facultatif) Pour une identité managée, activez l’identité affectée par le système sur le service appelant ou attachez une identité affectée par l’utilisateur, puis attribuez-lui un rôle sur la ressource Foundry.
- Supprimez l’authentification basée sur des clés après que tous les appelants utilisent l’authentification par jeton. Désactivez éventuellement l’authentification locale dans les modèles de déploiement.
Référence : Attribuer des rôles Azure | Contrôle d'accès basé sur les rôles pour Foundry
Résoudre les erreurs d’authentification courantes
| Erreur | Cause | Résolution |
|---|---|---|
| 401 Non autorisé | Jeton manquant ou expiré ; Clé API non valide | Vérifiez que l'étendue d'acquisition du jeton est https://ai.azure.com/.default. Régénérez la clé API si vous utilisez l’authentification basée sur des clés. |
| 403 Interdit | Attribution de rôle RBAC manquante | Attribuez le rôle intégré approprié (par exemple, Foundry User) à l’étendue de la ressource ou du projet. |
| AADSTS700016 | Application introuvable dans le locataire | Vérifiez que l’inscription de l’application existe dans le locataire approprié et que l’ID client est correct. |
| Sous-domaine personnalisé requis | La ressource utilise un point de terminaison régional au lieu d’un sous-domaine personnalisé | Configurez un sous-domaine personnalisé sur la ressource Foundry. L’authentification basée sur un jeton nécessite un sous-domaine personnalisé. |