Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Connexion de serveurs MCP

Les serveurs MCP (Model Context Protocol) étendent les capacités d'investigation de l' AWS DevOps Agent en fournissant un accès aux données provenant de vos outils d'observabilité externes, de vos systèmes de surveillance personnalisés et de vos sources de données opérationnelles. Ce guide explique comment connecter un serveur MCP à l' AWS DevOps agent.

Exigences

Avant de connecter un serveur MCP, assurez-vous que votre serveur répond aux exigences suivantes :

Considérations sur la sécurité

Lorsque vous connectez des serveurs MCP à l' AWS DevOps Agent, tenez compte des aspects de sécurité suivants :

Veuillez noter que la longueur maximale du nom d'outil de tout outil MCP est de 64 caractères. Pour connaître le nombre maximum d'outils MCP autorisés par espace d'agent, consultezQuotas.

Voir AWS DevOps Sécurité des agents pour plus d'informations sur l'injection rapide et le modèle de responsabilité partagée.

Serveurs MCP communautaires

Le référentiel AWS DevOps Agent Tools comprend des serveurs MCP déployables qui fournissent à l'agent des outils personnalisés pour des diagnostics approfondis de l'infrastructure, tels que la collecte des journaux des nœuds Amazon Elastic Kubernetes Service (Amazon EKS), l'analyse de la résolution DNS Amazon Virtual Private Cloud (Amazon VPC) et les contrôles de santé des bases de données Amazon Relational Database Service (Amazon RDS). Le référentiel est géré par l'équipe de service des AWS DevOps agents, et toutes les contributions passent par la même barre de vérification de sécurité avant d'être ajoutées. Pour découvrir ce qui est disponible, consultez le catalogue des serveurs MCP sur le GitHub site Web.

Pour utiliser un serveur MCP communautaire :

Enregistrement d'un serveur MCP (au niveau du compte)

Les serveurs MCP sont enregistrés au niveau du AWS compte et partagés entre tous les espaces d'agent de ce compte. Chaque espace d'agent peut ensuite choisir les outils spécifiques dont il a besoin pour chaque serveur MCP.

Étape 1 : détails du serveur MCP

Étape 2 : flux d'autorisation

Sélectionnez la méthode d'authentification pour votre serveur MCP :

Informations d'identification du client OAuth — Si votre serveur MCP utilise le flux d'informations d'identification du client OAuth :

OAuth 3LO (Three-Legged OAuth) — Si votre serveur MCP utilise OAuth 3LO pour l'authentification :

Clé API — Si votre serveur MCP utilise l'authentification par clé API :

En-têtes multi-authentification  : si votre serveur MCP attend un ou plusieurs secrets dans les en-têtes HTTP que vous nommez :

AWS SIGv4 — Si votre serveur MCP utilise l'authentification AWS Signature Version 4 :

Étape 3 : Configuration de l'autorisation

Configurez des paramètres d'autorisation supplémentaires en fonction de la méthode d'authentification sélectionnée :

Pour les informations d'identification du client OAuth :

Pour OAuth 3LO :

Pour la clé API :

Pour les en-têtes Multi Auth :

L'authentification multi-authentification envoie jusqu'à trois secrets à votre serveur MCP, chacun dans un en-tête que vous nommez. Utilisez-le pour les serveurs nécessitant plusieurs informations d'identification. Datadog, par exemple, attend une clé d'API DD-API-KEY et une clé d'application. DD-APPLICATION-KEY Un serveur qui a besoin d'un secret unique dans l'en-tête de votre choix fonctionne également.

AWS DevOps L'agent rejette les noms d'en-tête réservés par l'infrastructure HTTP ou le protocole MCP. Les noms réservés incluent Host Content-TypeContent-Length,Cookie, User-AgentAccept, etMcp-Session-Id. Les noms commençant parx-amz-,x-amzn-, x-forwarded-Proxy-, ou qui Sec- sont également rejetés. Authorizationest autorisé, vous pouvez donc enregistrer un serveur qui attend un jeton Authorization et un second secret dans un autre en-tête.

AWS DevOps L'agent stocke chaque secret chiffré et ne l'affiche plus une fois que vous avez enregistré le serveur. Conservez votre propre copie si vous avez besoin des valeurs ultérieurement. Cela diffère du champ facultatif d'en-têtes personnalisés de l'étape de configuration AWS SIGv4, qui envoie des valeurs en texte brut avec chaque demande signée.

Pour AWS SigV4 :

AWS L'authentification Sigv4 permet à AWS DevOps l'agent de se connecter aux serveurs MCP qui utilisent AWS Signature Version 4 pour la signature des demandes. Cela est utile pour les serveurs MCP hébergés sur Amazon API Gateway ou d'autres AWS services prenant en charge l'authentification SIGv4.

Étape 4 : Réviser et soumettre

Configuration des outils MCP dans un espace d'agent

Après avoir enregistré un serveur MCP au niveau du compte, vous pouvez configurer les outils de ce serveur qui sont disponibles pour des espaces d'agent spécifiques :

AWS DevOps L'agent pourra désormais utiliser les outils autorisés de votre serveur MCP lors des enquêtes dans cet espace d'agent.

Pour contrôler si l'agent peut invoquer un outil MCP en tant qu'action en lecture seule ou en mode mutation, vous devez classer chaque outil. Les outils que vous enregistrez par programmation sans définir toolDetails par défaut en lecture seule, et l'agent les exécute sans demander d'approbation. Pour plus d'informations sur la classification des outils MCP en lecture seule ou en mutation, consultez. Travailler avec des actions dirigées

Gestion des connexions au serveur MCP

Mise à jour des informations d'authentification  : vous pouvez mettre à jour les informations d'authentification d'un serveur MCP enregistré sans le désenregistrer. Accédez à la page Capability Providers dans la console de l' AWS DevOps agent, sélectionnez votre serveur MCP et choisissez Mettre à jour dans le menu Actions. Vos associations d'espace d'agent sont préservées. Ce que vous pouvez mettre à jour dépend de la méthode d'authentification :

Les serveurs MCP qui utilisent des informations d'identification client OAuth ou des en-têtes multi-authentification ne peuvent pas être mis à jour sur place. L'authentification multi-authentification des en-têtes est disponible uniquement lors de l'enregistrement. Il n'existe donc aucun chemin permettant de faire pivoter un secret ou de renommer un en-tête sur un serveur enregistré. Pour modifier ces informations d'identification, supprimez toutes les associations actives, désenregistrez le serveur MCP et réenregistrez-le avec les nouvelles valeurs.

Affichage des serveurs MCP connectés — Pour voir tous les serveurs MCP connectés à votre espace d'agent, sélectionnez votre espace d'agent, accédez à l'onglet Fonctionnalités et consultez la section Serveurs MCP. Vous pouvez également mettre à jour certains outils ici.

Suppression des connexions au serveur MCP — Pour déconnecter un serveur MCP d'un espace d'agents, sélectionnez le serveur dans la section Serveurs MCP et choisissez Supprimer. Pour supprimer complètement un enregistrement de serveur MCP, supprimez-le d'abord de tous les espaces d'agent, puis supprimez l'enregistrement au niveau du compte.

Création d'un rôle IAM pour l'authentification Sigv4

Lorsque vous utilisez l'authentification AWS Sigv4, AWS DevOps l'agent assume un rôle IAM dans votre compte pour signer les demandes adressées à votre serveur MCP. Ce rôle doit être doté d'une politique de confiance qui permet au principal du service de l' AWS DevOps agent (aidevops.amazonaws.com) de l'assumer, avec une protection adjointe confuse.

Politique d’approbation

Créez un rôle IAM avec la politique de confiance suivante. REGIONRemplacez-la par votre AWS région (par exempleus-east-1) et ACCOUNT_ID par votre identifiant de AWS compte.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "aidevops.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "ACCOUNT_ID"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:aidevops:REGION:ACCOUNT_ID:service/*"
        }
      }
    }
  ]
}

La politique de confiance inclut les conditions suivantes pour éviter le problème de confusion entre les députés  :

Politique d’autorisations

Associez une politique d'autorisations au rôle qui accorde les autorisations minimales requises pour appeler votre serveur MCP. Par exemple, si votre serveur MCP est hébergé derrière Amazon API Gateway, le rôle doit disposer d'une execute-api:Invoke autorisation sur la ressource API Gateway.

Multi-region signature (SigV4a)

Si votre serveur MCP est déployé dans plusieurs AWS régions, vous pouvez utiliser SIGv4a (Signature Version 4a) pour la signature multirégionale. Pour activer cela, entrez * comme AWS région lors de la configuration de l'autorisation SIGv4. SigV4a utilise une signature asymétrique, qui permet à une seule demande signée d'être valide dans plusieurs régions.

Cross-account accès sans rôle dédié

Au lieu d'enregistrer un rôle IAM dédié pour votre serveur MCP, vous pouvez utiliser l'enregistrement sans rôle  : enregistrez le serveur sans rôle et demandez à l' AWS DevOps agent de signer les demandes à l'aide d'un rôle IAM provenant d'un AWS compte déjà associé à votre espace agent. Cela est utile lorsque votre serveur MCP doit accéder à des ressources couvrant les AWS comptes principal et secondaire connectés à un espace d'agents, plutôt qu'un rôle unique limité à un seul compte.

Comment ça marche

Cross-account l'accès sans rôle dédié fonctionne comme suit :

Exigences

Avant d'associer un serveur MCP SIGv4 sans rôle à un espace d'agent :

Résolution des problèmes

L'association d'un serveur MCP sans rôle échoue : « nécessite une association de compte principal »

Si vous avez enregistré un serveur MCP sans rôle dédié et que l'association échoue, vérifiez le message d'erreur. Si l'erreur indique que le serveur nécessite une association de compte principal dans l'espace agent, aucun AWS compte principal n'est connecté à l'espace agent.

AWS DevOps L'agent valide un serveur MCP SIGv4 sans rôle lorsque vous l'associez, en utilisant le rôle IAM du compte principal AWS de l'espace agent. Pour résoudre ce problème :

Rubriques associées