Authentification et autorisation dans Microsoft Foundry

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 : Microsoft Entra ID 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.

Conditions préalables

• Un abonnement Azure. Si vous n’en avez pas, créez un compte gratuit.
• Ressource Microsoft Foundry avec un sous-domaine custome configuré.
• Compréhension des concepts de Azure RBAC.
• 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) Le 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 Azure plan de contrôle et 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.

Pour tous les exemples Bicep, Terraform et SDK, consultez le référentiel 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 de l'hôte de capacité du 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 les Microsoft Entra ID (basées sur des jetons, sans clé) et les clés API.

Microsoft Entra ID

Microsoft Entra ID utilise des jetons porteurs OAuth 2.0 définis pour https://ai.azure.com/.default.

Utilisez Microsoft Entra ID pour :

• Charges de travail de production.
• Accès conditionnel, authentification multifacteur (MFA) et accès juste-à-temps.
• RBAC avec privilège minimum et intégration d'identité gérée.

Avantages : attributions de rôles affinées, audit par principal, durées de vie des jetons contrôlables, hygiène des secrets automatiques 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 basé sur les rôles 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 Authentification sans clé avec Microsoft Entra ID.

S’authentifier avec Microsoft Entra ID (Python)

L’exemple suivant montre comment s’authentifier avec Microsoft Entra ID à l’aide de la bibliothèque azure-identity 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 ; Microsoft Entra ID 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())

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 quelles fonctionnalités de Foundry prennent en charge la clé API ou Microsoft Entra ID.

Types d’identités

Azure ressources et applications s’authentifient à l’aide de différents types d’identités, 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 offrent 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.

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.

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.

Configurer Microsoft Entra ID

Pour obtenir des conseils généraux sur la configuration de l’authentification Entra ID dans Foundry, consultez Authentification sans clé de configuration.

1. 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.

2. 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 :

   • Azure utilisateur IA : pour les développeurs qui doivent générer et tester avec des modèles prédéployés.
   • Azure AI Project Manager : pour les responsables d’équipe qui doivent créer des projets et gérer des déploiements.
   • Propriétaire du compte Azure AI : pour les administrateurs qui ont besoin d’une gestion complète des ressources et peuvent attribuer sous condition le rôle d'utilisateur Azure AI pour l’accès au plan des données.
   • Responsable de l'IA Azure : pour les utilisateurs qui ont besoin d'une gestion complète des ressources et d'un accès au plan de données. Exemple de commande CLI pour affecter le rôle d’utilisateur IA Azure :

   az role assignment create \
     --assignee <principal-id> \
     --role "Azure AI User" \
     --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<resource-name>
   

   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.

3. (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.

4. (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.

5. 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.

Reference : Assigner des rôles Azure | Contrôle d’accès en fonction du rôle pour Foundry

Résoudre les erreurs d’authentification courantes

Contenu connexe

• Contrôle d’accès en fonction du rôle pour Foundry
• Configurer l'authentification sans clé avec Microsoft Entra ID
• Faire pivoter les clés d’accès à l’API
• Rôles intégrés Azure (IA + apprentissage automatique)
• Authentication et autorisation (Microsoft Entra ID)
• Notions de base de l’identité