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 aux serveurs distants des DevOps agents

AWS DevOps L'agent fournit des serveurs distants dédiés pour les protocoles MCP (Model Context Protocol) et Agent-to-Agent (A2A). Utilisez ces serveurs pour connecter votre IDE, votre interface de ligne de commande ou vos intégrations d'agents personnalisées à un espace d'agents.

Protocoles pris en charge

Points de terminaison

Les serveurs distants sont disponibles via une URL régionale :

https://connect.aidevops.{region}.api.aws

Pour la liste des régions disponibles, consultezRégions prises en charge.

Authentification

Deux méthodes d'authentification sont disponibles pour les terminaux MCP et A2A :

Création d'un jeton d'accès

Conditions préalables

Activer les jetons d'accès

Création d'un jeton

Après avoir créé un jeton, l'application Web affiche un exemple de configuration que vous pouvez copier directement dans votre client.

Communiquez avec Kiro

Pour les utilisateurs de Kiro, une puissance d'AWS DevOps agent dédiée est disponible depuis l'IDE ou sur la place de marché Kiro Powers.

Étape 1 : Installation de l'alimentation

Installez aws-devops-agent power depuis la place de marché Powers.

Étape 2 : définir les variables d'environnement

Définissez les variables d'environnement suivantes pour configurer la connexion :

DEVOPS_AGENT_TOKEN=<your-access-token>
DEVOPS_AGENT_REGION=<your-agent-space-region>

Étape 3 : Approuver les variables dans Kiro

Accédez à Paramètres > Variables d'environnement approuvées par MCP, puis approuvez et. DEVOPS_AGENT_TOKEN DEVOPS_AGENT_REGION Kiro ne transmet pas les variables d'environnement aux serveurs MCP tant qu'elles ne sont pas approuvées.

Étape 4 : redémarrez Kiro

Redémarrez Kiro pour appliquer les modifications.

L'alimentation Kiro est incluse aws-mcp comme solution de secours, qui fournit un accès direct à AWS l'API lorsque le point de terminaison du serveur distant n'est pas disponible.

Communiquez avec Claude Code

Pour les utilisateurs de Claude Code, AWS DevOps Agent est disponible à partir du plugin Claude aws-agents-for-devsecops, qui intègre les fonctionnalités d'agent et AWS DevOps d'agent de sécurité dans Claude. AWS Installez-le depuis les plugins Claude ou depuis le dépôt des sources.

Connectez-vous à d'autres clients MCP

Pour n'importe quel MCP-compatible client, configurez le serveur avec :

Cette configuration fonctionne également avec Kiro et Claude Code si vous préférez configurer la connexion manuellement plutôt que d'utiliser l'alimentation ou le plug-in dédiés.

Exemple de configuration MCP :

{
  "mcpServers": {
    "aws-devops-agent": {
      "url": "https://connect.aidevops.{region}.api.aws/mcp",
      "headers": {
        "Authorization": "Bearer <your-access-token>"
      }
    }
  }
}

{region}Remplacez-la par la région de votre espace d'agent (par exempleus-east-1) et <your-access-token> par la valeur du jeton.

Utiliser l'authentification Sigv4

L'authentification Sigv4 utilise vos AWS informations d'identification au lieu d'un jeton d'accès. Les plugins Kiro power et Claude Code incluent le support SIGv4 intégré viamcp-proxy-for-aws, qui signe les demandes à l'aide de vos informations d'identification locales AWS .

Quand SIGv4 est utilisé

Conditions préalables

Exemple de configuration

Pour configurer un client MCP afin qu'il utilise SIGv4 au lieu d'un jeton d'accès, exécutez le serveur via. mcp-proxy-for-aws Remplacez {region} par la région de votre espace agent (par exemple,us-east-1) :

{
  "mcpServers": {
    "aws-devops-agent": {
      "command": "uvx",
      "timeout": 120000,
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://connect.aidevops.{region}.api.aws/mcp",
        "--service", "aidevops",
        "--region", "{region}"
      ]
    }
  }
}

Le proxy signe chaque demande avec vos AWS informations d'identification locales, aucun jeton d'accès n'est donc requis.

Multi-Agent-Space routage

En mode SIGv4, agent_space_id transmettez chaque appel d'outil pour spécifier l'espace d'agent à utiliser. Cela permet d'acheminer vers plusieurs espaces d'agent à partir d'un seul client.

Intégration A2A

Le point de terminaison A2A implémente la spécification A2A v1.0 à l'aide de la liaison HTTP+JSON.

En-têtes de demandes

Transmettez les en-têtes suivants aux requêtes A2A.

Découverte des cartes d'agent

Récupérez la carte d'agent à l'adresse suivante :

GET https://connect.aidevops.{region}.api.aws/.well-known/agent-card.json

Opérations prises en charge

Compétences

Considérations sur la sécurité

Définition de la portée des jetons

Liste d'adresses IP autorisées

Lors de la création d'un jeton d'accès, vous pouvez éventuellement spécifier une liste d'adresses IP autorisées. Une fois configuré, le jeton ne peut être utilisé qu'à partir des adresses IP ou des plages CIDR spécifiées. Les demandes provenant d'autres adresses IP sont rejetées avec une erreur d'accès refusé.

Rotation et révocation des jetons

Réagir à un jeton compromis

Si vous pensez qu'un jeton a été compromis, procédez comme suit :

Révocation de jetons par programmation

Vous pouvez également révoquer des jetons par programmation à l'aide de. awscurl Les commandes suivantes utilisent l'authentification SIGv4. Remplacez la région (us-east-1) par la région dans laquelle votre espace d'agent est créé.

Étape 1 : Répertoriez vos espaces d'agent

aws aidevops list-agent-spaces --region us-east-1

Étape 2 : Répertorier les jetons d'accès à un espace d'agent

awscurl --service aidevops --region us-east-1 \
  -H "Accept: application/json" \
  "https://cp.aidevops.us-east-1.api.aws/v1/agentspaces/{agentSpaceId}/access-tokens"

Étape 3 : révoquer un jeton

awscurl --service aidevops --region us-east-1 -X POST \
  -H "Accept: application/json" \
  "https://cp.aidevops.us-east-1.api.aws/v1/agentspaces/{agentSpaceId}/access-tokens/{accessTokenId}/revoke"

Remplacez {agentSpaceId} et {accessTokenId} par les valeurs des réponses précédentes.

Traçabilité

AWS DevOps L'agent enregistre l'activité du serveur distant dans AWS CloudTrail. Utilisez ces enregistrements pour savoir qui a appelé un serveur distant et ce que l'agent a fait en conséquence. AWS DevOps L'agent transmet les CloudTrail événements au AWS compte qui héberge l'espace agent.

Événements d'authentification par jeton d'accès

Chaque fois que AWS DevOps l'agent authentifie un jeton d'accès pour un point de terminaison MCP ou A2A, il envoie un événement à. AuthenticateAccessToken CloudTrail AWS DevOps L'agent enregistre les authentifications réussies et les échecs. Utilisez ces enregistrements pour auditer les utilisations légitimes et détecter les tentatives rejetées. Les exemples incluent les jetons expirés ou révoqués et les demandes bloquées par une liste d'adresses IP autorisées.

L'événement présente les caractéristiques suivantes :

L'événement inclut les domaines clés suivants :

Événements d'action en aval

Lorsque vous utilisez un jeton d'accès, AWS DevOps l'agent joue un rôle en votre nom pour effectuer des actions. AWS DevOps L'agent enregistre cet AssumeRole appel à l' CloudTrail aide de balises de session qui identifient le jeton et l'appelant :

Chaque action que l'agent effectue en votre nom est associée à un appel d' AWS API en aval correspondant qui est CloudTrail enregistré. Le nom de la session de rôle utilise ce formattoken_{spaceId}_{timestamp}_{tokenName}. Le nom de cette session correspond roleSessionName à celui de l'AuthenticateAccessTokenévénement. Utilisez-le pour effectuer le suivi d'une authentification jusqu'aux actions spécifiques qui l'ont suivie.

Invocations SigV4

Les appels qui utilisent l'authentification AWS SIGv4 au lieu d'un jeton d'accès ne produisent AuthenticateAccessToken aucun événement. AWS DevOps L'agent attribue les requêtes SIGv4 à votre AWS identité de gestion des identités et des accès (IAM). Vous pouvez suivre les actions que l'agent effectue via les appels d' AWS API en aval qu'il déclenche.

Limitation de la politique relative aux terminaux VPC

Les points de terminaison des serveurs distants ne prennent pas en charge les politiques relatives aux terminaux VPC. Les appels utilisant des jetons d'accès ou une authentification Sigv4 ne peuvent pas être limités par les politiques relatives aux terminaux VPC.

Désactivation des jetons d'accès

La fonctionnalité des jetons d'accès est désactivée par défaut. Pour le désactiver après l'avoir activé :

La désactivation bloque immédiatement tous les accès basés sur des jetons. Les jetons existants ne sont pas supprimés mais ne peuvent pas être utilisés tant que la fonctionnalité n'est pas réactivée.

Pour empêcher les utilisateurs de votre organisation d'activer les jetons d'accès, créez une politique de contrôle des services (SCP) qui refuse les actions de l'API des jetons d'accès et l'UpdateAgentSpaceaction (qui contrôle le basculement des jetons d'accès) :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAccessTokenOperations",
      "Effect": "Deny",
      "Action": [
        "aidevops:UpdateAgentSpace",
        "aidevops:CreateAccessToken",
        "aidevops:GetAccessToken",
        "aidevops:ListAccessTokens",
        "aidevops:RotateAccessToken",
        "aidevops:RevokeAccessToken"
      ],
      "Resource": "*"
    }
  ]
}

Résolution des problèmes