Vous pouvez créer des règles d'accès unifié (UAP) IAM (Identity and Access Management) pour sécuriser la communication entre les principaux d'agent et les ressources de destination, telles que les agents de destination, les serveurs MCP et les points de terminaison. Ces stratégies sont liées au projet qui contient vos instances Agent Gateway.
Agent Gateway utilise Identity-Aware Proxy (IAP) pour évaluer et appliquer les règles d'accès unifiées.
IAP s'intègre également à l'Accès contextuel pour fournir une authentification et une autorisation de bout en bout de l'identité de l'agent.
Pour configurer des UAP pour Agent Gateway, consultez Configurer des UAP IAM.
Vous pouvez également créer une limite d'accès des principaux (PAB) sur l'identité de l'agent. Agent Gateway peut utiliser IAP pour appliquer des stratégies Limite d'accès des principaux.
Activer Agent Gateway
Pour utiliser des règles de communication agentiques, vous devez configurer Agent Gateway.
Nous vous recommandons de configurer Agent Gateway en mode dry run (DRY_RUN) dans un environnement de préproduction pour vérifier que vos règles fonctionnent comme prévu.
Lorsque vous êtes certain que les règles fonctionnent correctement, vous pouvez mettre à jour la configuration d'Agent Gateway pour définir le mode forcé sur ENFORCE. Dans ce mode, les communications d'agent qui ne respectent pas la règle sont refusées, et la communication avec la ressource est bloquée.
Présentation des UAP
Les UAP contrôlent si un ou plusieurs principaux d'agent peuvent accéder à une ou plusieurs ressources de destination. Les PAU étendent le modèle de stratégie IAM en acceptant plusieurs règles dans une même stratégie. Contrairement aux stratégies d'autorisation et de refus IAM, chaque règle d'une stratégie d'accès universel peut avoir à la fois un effet d'autorisation et un effet de refus. En savoir plus sur les types de stratégies IAM.
Les règles contiennent également des conditions exprimées en langage CEL (Common Expression Language). Les conditions constituent le principal mécanisme de contrôle de l'accès aux ressources post-passerelle. L'application des règles d'accès utilisateur avec Agent Gateway et IAP permet de contrôler de manière stricte le comportement des agents déployés dans votre entreprise. Vous pouvez représenter des cas d'utilisation réels et précis de gouvernance des agents dans une seule stratégie.
Une stratégie type contient au moins deux règles distinctes :
- Règle d'autorisation : les règles d'autorisation ont un effet d'autorisation qui permet aux principaux d'agent d'accéder à des opérations spécifiques et sûres, comme effectuer une opération de lecture sur un outil pour récupérer des données de suivi ou afficher des entrées de registre.
- Règle de refus : les règles de refus ont un effet de refus qui empêche l'agent d'exécuter des actions indésirables, telles que l'exécution d'une opération de suppression ou de mise à jour non commandée sur une ressource critique.
Prenons l'exemple d'un agent d'assistance client automatisé qui doit interagir avec des outils internes disposant d'un accès privilégié à une base de données client. L'administrateur configure une Agent Gateway avec IAP pour appliquer les UAP IAM. L'administrateur peut configurer une UAP avec une règle d'autorisation qui permet au principal d'agent de lire les demandes d'assistance, et une règle de refus qui empêche le principal d'agent de supprimer ou de mettre à jour des enregistrements de base de données.
En utilisant des règles d'accès utilisateur contenant à la fois des règles d'autorisation et de refus, les organisations peuvent déployer une seule règle de conformité d'entreprise directement sur l'infrastructure cloud sous-jacente pour limiter le comportement des agents.
Bonnes pratiques
Suivez ces bonnes pratiques lorsque vous configurez des règles de sortie de l'agent :
- Utilisez le mode dry run : déployez d'abord les règles nouvelles ou modifiées en mode dry run pour vous assurer qu'elles fonctionnent comme prévu, sans bloquer le trafic des agents actifs.
- Appliquez le principe du moindre privilège : n'accordez que les autorisations nécessaires. Utilisez des noms ou des chemins d'accès d'outils spécifiques dans les conditions CEL plutôt que des caractères génériques.
- Utilisez des règles de refus pour les garde-fous : utilisez des règles de refus explicites pour mettre en œuvre des garde-fous critiques, comme le blocage des outils destructeurs sur les points de terminaison de production. L'utilisation de règles de refus pour les garde-fous est efficace, car les règles de refus prévalent sur les règles d'autorisation.
- Effectuez des audits réguliers : examinez régulièrement les journaux Cloud Audit Logs et les configurations de règles pour vérifier qu'ils sont conformes aux règles de sécurité de votre organisation.
Composants UAP
Les règles d'accès utilisateur contiennent une ou plusieurs règles. Les règles se composent des éléments suivants :
Principaux d'agent
Dans vos UAP IAM, vous définissez un ou plusieurs principaux d'agent. Les principaux d'agent sont les membres auxquels vous accordez l'accès. Vous spécifiez les agents par leur identité, c'est-à-dire l'identité de l'agent qui initie la communication avec une ressource.
Pour en savoir plus sur la façon dont les différents types d'agents reçoivent des identités, consultez Identité de l'agent.
Les identités d'agent sont représentées par des identifiants de principal qui contiennent l'identité de l'agent au format SPIFFE (par exemple, principal://agents.global.org-...).
Vous pouvez spécifier un tableau d'identités d'agents individuels ou un tableau d'ensembles de comptes principaux.
Les identités d'agent intégrées sont provisionnées dans les services Cloud de Confiance tels que Agent Runtime (moteur de raisonnement), Gemini Enterprise (Discovery Engine) et les services Cloud Run configurés avec l'identité d'agent. Ces principaux d'agent se présentent sous la forme principal://TRUST_DOMAIN/AGENT_UNIQUE_IDENTIFIER, où l'identifiant représente le chemin d'accès à la ressource de l'agent sur son service d'hébergement.
Vous pouvez également spécifier des agents à l'aide d'identifiants de comptes principaux de la fédération d'identité de charge de travail.
Effet de la règle
L'effet de la règle définit si elle autorise ou non les principaux d'agent à accéder à une ressource.
Ressources de destination
Les règles d'accès utilisateur IAM gèrent l'accès des principaux d'agent aux ressources de destination. Les ressources de destination sont les ressources auxquelles les principaux d'agent tentent d'accéder. Les ressources de destination sont spécifiées dans les conditions de la règle. Les ressources de destination peuvent être des ressources enregistrées ou des ressources non enregistrées.
Ressources enregistrées
Les ressources enregistrées sont des ressources enregistrées dans un registre Agent Registry.
Les ressources enregistrées incluent les éléments suivants :
- Registres : registres d'agents entiers dans un projet.
- Serveurs MCP : serveurs MCP enregistrés dans un registre d'agents.
- Agents : agents enregistrés dans un registre d'agents. Les agents individuels peuvent être spécifiés individuellement par leur identité d'agent. Un groupe d'agents peut être spécifié par un identifiant d'ensemble de comptes principaux.
- Points de terminaison : points de terminaison enregistrés dans un registre d'agents.
Les services individuels peuvent être enregistrés dans Agent Registry. Si vous régionalisez vos registres d'agents et que votre règle gère l'accès aux ressources enregistrées, vos UAP ne s'appliquent qu'aux ressources situées dans la région du registre.
Ressources non enregistrées
Les ressources non enregistrées sont des ressources qui ne sont pas enregistrées dans un registre d'agents. Pour autoriser ou refuser l'accès à des ressources non enregistrées dans vos règles de stratégie d'accès unifiée, vous devez spécifier des ressources non enregistrées dans les conditions de votre règle à l'aide d'expressions CEL (Common Expression Language) contenant des attributs d'hôte et de chemin d'accès non enregistrés.
Conditions
Dans les règles de stratégie d'accès utilisateur, vous utilisez des expressions CEL (Common Expression Language) dans le bloc conditions pour définir à la fois le champ d'application de la ressource cible et les critères d'accès précis :
Champ d'application de la ressource cible : identifie les ressources de destination auxquelles la règle s'applique. Dans les fichiers de stratégie au format JSON, vous spécifiez des attributs de destination, tels que
destination.agent_registry.mcp_server.nameoudestination.unregistered.host. Dans la console Cloud de Confiance , la sélection de destinations sous Ressources cibles ajoute automatiquement ces critères de ressources à l'expression de condition de la règle.Critères d'accès : utilisez une expression booléenne pour déterminer quand et sous quelles contraintes l'effet de la règle s'applique. Par exemple, vous pouvez limiter l'accès en fonction des noms d'outils, de l'état en lecture seule, des méthodes HTTP ou des préfixes de chemin d'accès à l'aide des attributs CEL UAP. L'effet de la règle (autoriser ou refuser) ne prend effet que lorsque l'expression CEL entière est évaluée à
true.
Dans la gcloud CLI et l'API REST, vous spécifiez ces expressions CEL dans le champ conditions de la définition de la règle.
Dans la console Cloud de Confiance , vous pouvez configurer des règles standards à l'aide du générateur de conditions ou écrire des expressions CEL personnalisées directement dans l'éditeur de conditions.
Autorisations
Dans IAP V2 avec les UAP IAM, l'autorisation iap.googleapis.com/resources.egressViaIAP est toujours accordée sur la ressource de destination. Dans gcloud CLI et l'API REST, vous spécifiez l'autorisation dans le champ operation.permissions de votre fichier de stratégie.
Options de création de règles
Sur la page Stratégies de la console Cloud de Confiance , vous pouvez créer des stratégies d'accès utilisateur IAM. Nous vous recommandons de ne créer que des UAP (stratégies IAM v3).
Dans la gcloud CLI et l'API REST, vous pouvez configurer des règles d'accès utilisateur IAM en créant d'abord un fichier au format JSON. Nous vous recommandons de ne créer que des UAP.
Authentification et autorisation de bout en bout
IAP et l'accès contextuel fournissent par défaut une authentification et une autorisation de bout en bout de l'identité de l'agent à l'aide des protocoles suivants :
- TLS mutuelle (mTLS)
- Démonstration de preuve de possession (DPoP)
Les identités d'agent sont provisionnées avec un certificat X.509 et un jeton lié au certificat. IAP impose aux identités d'agent d'utiliser le protocole TLS mutuel (mTLS) pour s'authentifier auprès d'Agent Gateway. Lorsque la passerelle autorise l'agent à sortir et à accéder aux API Cloud de Confiance , aux serveurs MCP, aux autres agents et aux points de terminaison, l'agent tente d'accéder en dehors de la limite mTLS. Pour protéger les communications, l'accès contextuel applique une règle d'accès contextuel gérée par Google. La règle exige que DPoP valide le jeton lié au certificat qui est lié à l'identité de l'agent. Pour en savoir plus sur la façon dont l'accès contextuel utilise mTLS et DPoP, consultez Sécurité de l'agent d'accès contextuel.
Attributs CEL UAP
Dans vos règles d'accès utilisateur, vous pouvez définir des conditions à l'aide d'expressions conditionnelles. Les expressions peuvent contenir plusieurs sous-expressions. Le type de ressource de destination que vous utilisez dans chaque sous-condition relationnelle détermine les attributs que vous pouvez utiliser.
Par exemple, dans la condition suivante, dans la sous-expression destination.unregistered.path.startsWith('/v1/statements'), le type de ressource est une destination non enregistrée, l'attribut est destination.unregistered.path et startsWith() est la fonction CEL.
destination.unregistered.host == 'finance.example.com' &&
destination.unregistered.path.startsWith('/v1/statements')
Les attributs décrits dans le tableau suivant sont disponibles pour chaque type de ressource :
| Type de ressource de destination | Attribut | Détails | ||||||
|---|---|---|---|---|---|---|---|---|
Agent Registry |
destination.is_registered |
|
||||||
destination.agent_registry.resource_type |
|
|||||||
destination.agent_registry.location |
|
|||||||
destination.agent_registry.project_id |
|
|||||||
Agent |
destination.agent_registry.agent.name |
|
||||||
Serveur MCP |
destination.agent_registry.mcp_server.name |
|
||||||
destination.agent_registry.mcp_server.method |
|
|||||||
destination.agent_registry.mcp_server.tool.name |
|
|||||||
destination.agent_registry.mcp_server.tool.annotations.read_only_hint
|
|
|||||||
destination.agent_registry.mcp_server.tool.annotations.destructive_hint
|
|
|||||||
destination.agent_registry.mcp_server.tool.annotations.idempotent_hint
|
|
|||||||
destination.agent_registry.mcp_server.tool.annotations.open_world_hint
|
|
|||||||
destination.agent_registry.mcp_server.prompt.name |
|
|||||||
destination.agent_registry.mcp_server.resource.name |
|
|||||||
Point de terminaison |
destination.agent_registry.endpoint.name |
|
||||||
Destination non enregistrée |
destination.unregistered.host |
|
||||||
destination.unregistered.path |
|
|||||||
destination.unregistered.method |
|
Étapes suivantes
- Attributs CEL pour les règles d'accès des utilisateurs
- Créer des règles d'accès utilisateur IAM
- Gérer les règles d'accès utilisateur IAM
- Résoudre les problèmes liés aux règles d'accès utilisateur IAM
Atelier de programmation : Sécuriser les applications d'IA agentique cross-cloud
Découvrez comment sécuriser vos applications agentiques dans l'atelier de programmation "Sécuriser les applications d'IA agentique cross-cloud".