Limites interprojets

Aperçu

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Les limites de gestion multiprojet (ou limites) vous permettent de découvrir, de gérer et de gouverner des agents IA, des serveurs MCP (Model Context Protocol) et des outils dans plusieurs projets Google Cloud . Agent Registry fonctionne par défaut dans un seul projet de gouvernance, mais la configuration d'une limite de gestion dans Resource Manager permet à un projet de gestion central d'agréger les agents, les serveurs MCP et les outils dans des projets membres distribués. Comprendre comment les limites de gestion structurent les rôles de projet, l'agrégation des ressources et le contrôle des accès vous aide à concevoir des topologies multiprojets évolutives.

Pour configurer une limite de gestion, consultez Configurer une limite de gestion pour plusieurs projets.

Modèle de limite

Vous définissez une limite de gestion sur un dossier ou une organisation dans Resource Manager :

• Limite à l'échelle d'un dossier ou d'une organisation : par défaut, si vous créez une limite sur un dossier ou une organisation sans configurer de filtre de tag, la limite inclut tous les projets enfants de ce dossier ou de cette organisation en tant que projets membres.
• Limites filtrées par tag (facultatif) : vous pouvez éventuellement partitionner les projets enfants d'un dossier ou d'une organisation en plusieurs limites en filtrant l'appartenance aux limites à l'aide de tags Resource Manager. Par exemple, vous pouvez séparer les environnements prod et dev. Vous associez des tags aux projetsGoogle Cloud que vous souhaitez inclure dans chaque limite. Lorsqu'un projet enfant du dossier ou de l'organisation possède un tag correspondant au filtre de limite, ce projet devient un projet membre de la limite de gestion.

Lorsque vous utilisez des tags pour partitionner les limites de gestion, les tags offrent les avantages suivants :

• Enregistrement dynamique et automatisé : les environnements cloud modifient fréquemment les projets. Lorsque vous ajoutez un tag à un projet avec une valeur de tag enregistrée, telle que env=prod, Agent Registry inclut automatiquement ce projet en tant que projet membre dans la limite, sans nécessiter de mises à jour manuelles des définitions de limite.
• Dissociation des hiérarchies de dossiers : les structures de dossiers Resource Manager sont généralement organisées à des fins de facturation ou d'activité. Les tags dissocient les définitions de limites des hiérarchies de dossiers physiques, ce qui vous permet d'établir des périmètres de gestion entre dossiers dans un dossier ou une organisation parent.
• Héritage et évolutivité : les tags appliqués à une organisation ou à un dossier se propagent automatiquement dans la hiérarchie des ressources vers les dossiers et projets enfants. Ce modèle d'héritage vous permet d'enregistrer des branches entières de votre arborescence de ressources avec une seule attribution de tag.
• Gouvernance centralisée : les tags sont régis par des autorisations IAM (Identity and Access Management) centralisées. En utilisant des tags pour définir des limites de gestion, vous pouvez empêcher des utilisateurs individuels d'ajouter ou de supprimer arbitrairement des projets de la limite.

Architecture et ressources clés

Une limite de gestion inter-projets repose sur les ressources Resource Manager suivantes :

• Configuration de limite (ressource BoundaryConfig) : ressource de configuration sur une organisation ou un dossier dans Resource Manager qui établit les règles de partitionnement des limites dans ce dossier ou cette organisation. Si vous ne définissez pas de clé de tag sur la ressource BoundaryConfig, l'organisation ou le dossier n'accepte qu'une seule limite incluant tous ses projets enfants. Pour partitionner les projets enfants en plusieurs limites filtrées par tag, la ressource BoundaryConfig spécifie la clé de tag de ressource unique, telle que 123456789012/env, utilisée pour évaluer l'appartenance du projet à ce dossier ou à cette organisation.

• Limite (ressource Boundary) : périmètre des projets membres d'une organisation ou d'un dossier. Sans filtre de tag, la limite inclut tous les projets enfants de l'organisation ou du dossier parent. Lorsque vous configurez une clé de tag sur la ressource BoundaryConfig parente, la ressource Boundary spécifie un filtre de valeur de tag, tel que env=prod, et les projets enfants qui héritent de cette valeur de tag ou l'associent appartiennent automatiquement à la limite. Étant donné que la ressource BoundaryConfig d'un parent utilise une seule clé de tag et qu'un projet ne peut avoir qu'une seule valeur de tag effective par clé de tag, un projet peut appartenir à une seule limite par dossier ou organisation parent.

• Configuration des fonctionnalités (ressource CapabilityConfig) : ressource définie sur une organisation, un dossier ou un projet. Au niveau de l'organisation ou du dossier, elle lie une ou plusieurs limites à un projet de gestion dédié et spécifie les fonctionnalités de gestion activées dans ces limites. Au niveau du projet, il permet de gérer un seul projet autonome sans limites. Pour Agent Registry, vous configurez la fonctionnalité AGENT_MANAGEMENT (Google Cloud CLI : agent-management), qui permet la découverte centralisée des composants, les cumuls de recherche et la gouvernance multiprojet dans Agent Registry, et active automatiquement agentregistry.googleapis.com sur le projet de gestion.

Pour en savoir plus sur ces ressources Resource Manager, consultez Présentation des limites et des fonctionnalités de gestion.

Le schéma suivant illustre comment les ressources Resource Manager connectent les projets membres à un projet de gestion centralisé :

Figure 1. Architecture d'une limite de gestion inter-projets connectant des projets membres à un projet de gestion centralisé.

Gestion multiprojets

Une limite de gestion sépare la gouvernance administrative de l'exécution du calcul entre deux rôles de projet distincts : un projet de gestion central et un ou plusieurs projets membres.

Cette structure dissociée applique l'isolation mutualisée. Les équipes créent et déploient des agents dans leurs projets membres respectifs sans avoir besoin d'un accès direct aux autres projets membres. Les administrateurs et les orchestrateurs conservent une visibilité unifiée sur la limite de gestion depuis le projet de gestion.

Projet de gestion

Un projet de gestion est un projet Google Cloud qui sert de projet de gouvernance central pour une limite de gestion. Il centralise la configuration des API, le contrôle des accès, la facturation, la consommation des quotas et les métadonnées des composants agrégés au-delà de la limite, sans qu'il soit nécessaire d'héberger des environnements d'exécution de calcul sous-jacents.

Dans Agent Registry, le projet de gestion remplit les fonctions suivantes :

• Liaison de limites et de fonctionnalités : associe une ou plusieurs limites dans Resource Manager via une ressource CapabilityConfig pour laquelle la fonctionnalité AGENT_MANAGEMENT est activée. Pour connaître la procédure de configuration, consultez Configurer les limites de gestion.
• Détection et recherche centralisées : sert de projet cible pour les requêtes de liste et de recherche multiprojets, ce qui permet aux orchestrateurs, aux développeurs et aux applications clientes d'interagir avec les agents, les serveurs MCP et les outils détectés automatiquement dans tous les projets membres de la limite.
• Enregistrement des ressources à l'échelle de la limite : héberge les ressources Service enregistrées manuellement, telles que les agents personnalisés, les serveurs MCP externes et les points de terminaison, ainsi que les ressources Binding lorsque vous souhaitez que ces ressources soient visibles dans la limite de gestion.
• Gestion centralisée des API, de la facturation et des quotas : consolide l'activation de l'API Agent Registry, l'allocation des quotas et la facturation pour les opérations de découverte et de gouvernance au niveau des limites.

Lorsque vous configurez une ressource CapabilityConfig sur un dossier ou une organisation dans Resource Manager, vous pouvez provisionner votre projet de gestion de l'une des manières suivantes :

• Projet de gestion autogéré : vous désignez un projetGoogle Cloud existant que vous gérez en transmettant l'option --management-project lorsque vous créez la ressource CapabilityConfig. Le projet doit résider directement dans le même dossier ou la même organisation parent que la ressource CapabilityConfig et ne peut pas déjà servir de projet de gestion pour une autre ressource CapabilityConfig. Si vous supprimez ultérieurement la ressource CapabilityConfig, Resource Manager conserve votre projet autogéré et le convertit en projet standard.
• Projet de gestion géré par Google : vous omettez l'option --management-project lorsque vous créez la ressource CapabilityConfig, et Resource Manager crée et gère automatiquement un nouveau projet pour vous dans le dossier ou l'organisation parent. Le projet généré comporte un préfixe d'ID de projet google-mpf ou google-mpo. Si vous supprimez ultérieurement la ressource CapabilityConfig, Resource Manager supprime ce projet géré par Google.

Dans les deux cas, la création de la ressource CapabilityConfig avec agent-management active automatiquement agentregistry.googleapis.com sur le projet de gestion.

Projets des membres

Les projets membres sont les projets Google Cloud qui appartiennent à une limite de gestion. Il peut s'agir de tous les projets enfants du dossier ou de l'organisation parent de la limite, ou des projets enfants qui correspondent à un filtre de tag de limite facultatif tel que env=prod. Les agents, les serveurs MCP et les outils détectés automatiquement s'exécutent dans les projets membres.

Les projets membres conservent leurs propres ressources de calcul locales, telles que les moteurs de raisonnement Agent Runtime, les services Cloud Run ou les clusters GKE. Les ressources détectées automatiquement sont ingérées localement dans chaque projet membre et agrégées dans le projet de gestion lorsque vous listez ou recherchez le registre. En revanche, les ressources enregistrées manuellement que vous créez dans un projet membre ne sont visibles que lorsque vous envoyez une requête à ce projet membre individuel.

L'association de projets membres à un projet de gestion dans une limite est soumise à des limites système. Le dépassement de cette limite peut entraîner des erreurs de cumul. Pour en savoir plus, consultez Quotas et limites du système.

Enregistrement et cumul

La découverte interprojets dans le registre d'agents distingue les ressources découvertes automatiquement et déployées dans les projets membres des ressources enregistrées manuellement et limitées au projet dans lequel elles sont créées.

Ressources détectées et enregistrées automatiquement

La façon dont une ressource est limitée au sein d'une limite de gestion dépend de la façon dont elle est enregistrée :

• Agents et serveurs MCP détectés automatiquement : les ressources compatibles déployées dans les projets membres, telles que les moteurs de raisonnement Agent Runtime, les services Cloud Run et les déploiements GKE, sont automatiquement ingérées dans le projet membre où elles sont déployées et agrégées dans le projet de gestion.

• Ressources et liaisons enregistrées manuellement : les ressources Service enregistrées manuellement, telles que les agents personnalisés, les serveurs MCP externes, les points de terminaison et les ressources Binding, sont limitées au projet dans lequel elles sont créées :

  • Créez-les dans le projet de gestion si vous souhaitez qu'ils soient visibles au-delà de la limite de gestion.
  • Créez-les dans un projet membre si vous souhaitez qu'ils ne soient visibles que dans ce projet membre.

• Compétences, éditeurs et applications d'IA autonomes : les ressources autonomes personnalisées Skill, SkillRevision, Publisher et AiApplication sont limitées au projet dans lequel elles sont créées et ne sont pas agrégées entre les projets membres d'une limite de gestion. Enregistrez des compétences autonomes personnalisées et des applications d'IA dans le projet où vos agents ou développeurs doivent les découvrir. Les compétences autonomes gérées par Google sont automatiquement détectables dans n'importe quel projet.

Regroupement centralisé des requêtes

La façon dont le registre d'agents définit le champ d'application des emplacements dépend de si vous interrogez un projet de gouvernance autonome, ou un projet membre ou un projet de gestion dans une limite de gestion :

• Projets de gouvernance autonomes et projets membres : les requêtes dans un emplacement compatible avec Agent Registry, tel que us-central1, europe-west1, us, eu ou global, ne renvoient que les ressources de cet emplacement pour ce projet unique, sans cumul interprojets.

• Projet de gestion : lorsque vous activez une ressource CapabilityConfig avec agent-management sur un projet de gestion, le cumul multiprojet est compatible avec tous les emplacements compatibles avec le registre d'agents. L'interrogation d'un emplacement sur le projet de gestion agrège les ressources de ce même emplacement dans le projet de gestion et tous les projets membres de la limite de gestion. Ce cumul n'inclut pas les ressources de différents emplacements :

  • Régions uniques : les requêtes dans une seule région, comme us-central1 ou europe-west1, agrègent les agents et les serveurs MCP détectés automatiquement et déployés dans cette région unique dans le projet de gestion et ses projets membres, ainsi que les ressources Service et Binding créées dans cette région sur le projet de gestion.
  • Emplacements multirégionaux : les requêtes dans un emplacement multirégional, tel que us ou eu, agrègent les agents et les serveurs MCP détectés automatiquement et déployés dans cet emplacement multirégional dans le projet de gestion et ses projets membres. Les requêtes dans des emplacements multirégionaux n'agrègent pas les ressources déployées dans des emplacements régionaux.
  • Global : les requêtes dans l'emplacement global agrègent les agents et les serveurs MCP détectés automatiquement et déployés dans global sur le projet de gestion et ses projets membres, ainsi que les ressources Service et Binding créées dans global sur le projet de gestion. Les requêtes dans global n'agrègent pas les ressources déployées dans des emplacements multirégionaux ou des régions uniques.

Lorsque vous listez, recherchez ou récupérez des composants agentifs dans un emplacement du projet de gestion, Agent Registry effectue les étapes suivantes :

1. Identifie tous les projets membres associés au projet de gestion via la ressource CapabilityConfig active.
2. Interroge les agents et les serveurs MCP détectés automatiquement à cet emplacement dans le projet de gestion et chaque projet membre, ainsi que toutes les ressources Service enregistrées manuellement créées à cet emplacement dans le projet de gestion.
3. Regroupe les ressources correspondantes dans un ensemble de résultats unifié.
4. Il vous renvoie les résultats agrégés.

Si plusieurs limites sont associées à la même ressource CapabilityConfig, le registre d'agents regroupe les projets membres de toutes les limites associées dans le même registre de projet de gestion. Pour limiter la liste ou les résultats de recherche du projet de gestion à un seul projet membre, transmettez --filter="project_id=MEMBER_PROJECT_ID". Si deux environnements nécessitent une visibilité distincte, créez une ressource CapabilityConfig et un projet de gestion distincts pour chaque limite.

La découverte d'un seul projet et la découverte multiprojet utilisent des méthodes d'API identiques. Le champ d'application de la recherche dépend du fait que le projet ciblé est un projet membre ou un projet de gestion.

Noms de ressources au-delà d'une limite de gestion

Lorsqu'un composant est inclus dans un projet membre, Agent Registry lui attribue un ID, tel que AGENT_ID ou SERVER_ID. Lorsque vous listez, recherchez ou obtenez un composant au-delà d'une limite de gestion, le registre d'agents conserve l'ID de ce composant et met en forme le nom de ressource associé en fonction du projet que vous utilisez :

• Projet de gestion : lorsque vous listez, recherchez ou obtenez des composants à l'aide du projet de gestion, chaque nom de ressource utilise le projet de gestion.
• Projet membre : lorsque vous listez, recherchez ou obtenez des composants à l'aide du projet membre dans lequel la ressource est déployée, chaque nom de ressource utilise ce projet membre.

Le tableau suivant présente l'URL de la requête et le nom de ressource associé pour les ressources détectées automatiquement déployées dans un projet membre :

Type de ressource	Request URL	Nom de la ressource associée
Agent	projects/MANAGEMENT_PROJECT_ID/locations/LOCATION/agents/AGENT_ID	projects/MANAGEMENT_PROJECT_ID/locations/LOCATION/agents/AGENT_ID
	projects/MEMBER_PROJECT_ID/locations/LOCATION/agents/AGENT_ID	projects/MEMBER_PROJECT_ID/locations/LOCATION/agents/AGENT_ID
Serveur MCP	projects/MANAGEMENT_PROJECT_ID/locations/LOCATION/mcpServers/SERVER_ID	projects/MANAGEMENT_PROJECT_ID/locations/LOCATION/mcpServers/SERVER_ID
	projects/MEMBER_PROJECT_ID/locations/LOCATION/mcpServers/SERVER_ID	projects/MEMBER_PROJECT_ID/locations/LOCATION/mcpServers/SERVER_ID

Le nom de la ressource associée reflète le projet de votre requête. Toutefois, l'identifiant de registre et la référence d'exécution du composant restent immuables et conservent toujours le projet membre dans lequel la charge de travail sous-jacente s'exécute.

Visualisation de la topologie et des flux de trafic

Les administrateurs de plate-forme et les architectes IA peuvent visualiser les relations multi-agents et le trafic interprojets à l'aide du graphique de topologie.

Le graphique de topologie visualise les dimensions architecturales suivantes :

• Corrélation de la référence d'exécution : met en corrélation l'identifiant d'agent logique avec sa référence d'exécution physique. Cette corrélation permet aux opérateurs de tracer un agent dans Agent Registry directement vers son moteur de raisonnement Agent Runtime, son service Cloud Run ou son déploiement GKE sous-jacent.
• Liaisons interprojets : affiche les liaisons entre les agents orchestrateurs d'un projet et les serveurs MCP ou les outils en aval d'un autre projet.
• Vérification du périmètre : aide les administrateurs à vérifier que la communication de l'agent est conforme aux périmètres VPC Service Controls et qu'elle est acheminée via les points de terminaison Agent Gateway désignés.

Contrôle des accès

Dans une limite de gestion, vous accordez des rôles de découverte IAM sur le projet de gestion afin que les utilisateurs et les orchestrateurs puissent effectuer des recherches dans la limite sans avoir besoin d'un accès IAM direct aux projets membres individuels. Étant donné que les ressources Service et Binding enregistrées manuellement et créées dans un projet membre ne sont pas cumulées dans le projet de gestion, les administrateurs de sécurité peuvent également limiter la création locale de Service et Binding dans les projets membres à l'aide d'une contrainte de règle d'administration ou d'une stratégie de refus IAM. Lorsque les agents des projets membres appellent des outils ou communiquent avec des agents d'autres projets au-delà de la limite, le trafic peut être acheminé via une Agent Gateway centrale.

Pour les ressources d'une limite de gestion, les restrictions VPC Service Controls ne s'appliquent qu'aux interactions du registre d'agents dans le projet de gestion. Agent Registry peut découvrir des agents et des serveurs MCP dans tous les projets membres de la limite de gestion, même si ces projets membres ne se trouvent pas dans le même périmètre de service que le projet de gestion.

Pour en savoir plus sur les rôles requis pour la configuration des limites, l'accès au registre et les restrictions d'écriture des projets membres, consultez Rôles pour les limites de gestion multiprojets.

Étapes suivantes

• Configurez les limites de gestion dans Resource Manager.
• En savoir plus sur le modèle de données multiprojets
• Rechercher au-delà d'une limite de gestion
• Consultez la section Rôles et autorisations pour Agent Registry.