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.

Travailler avec des actions dirigées

AWS DevOps L'agent peut agir sur vos services et AWS comptes connectés lorsqu'un opérateur le lui demande explicitement. Par exemple, un opérateur enquêtant sur un incident peut demander à l'agent de décrire l'état d'une ressource. Avec les autorisations et approbations appropriées, l'opérateur peut également demander à l'agent de résoudre directement un problème.

L'agent distingue deux types d'opérations :

Le modèle de sécurité pour les actions dirigées est la défense en profondeur. La fonctionnalité est désactivée par défaut. Vous vous inscrivez par le biais de couches indépendantes : activation des actions dirigées sur l'espace agent, enregistrement d'un rôle IAM par compte et catégorisation de chaque outil. Chaque action dirigée nécessite l'approbation de l'opérateur au moment de son exécution. Chaque approbation et chaque action qui en résulte sont attribuables à l'opérateur approbateur dans AWS CloudTrail.

Pour les actions contre les AWS ressources, l'agent applique ses propres mesures de protection aux opérations du AWS SDK qu'il invoque, indépendamment des autorisations que vous accordez. Pour plus d'informations sur ces garde-corps, consultez la section Opérations que l'agent n'effectuera pas.

Exemple : exécution d'un plan d'atténuation à partir d'une enquête

Cet exemple montre l'expérience de bout en bout pour un scénario courant. Un opérateur passe en revue le plan d'atténuation issu d'une enquête ou d'une recommandation d'amélioration. L'opérateur demande à l'agent de l'exécuter sans quitter la conversation.

Un ingénieur en fiabilité du site (SRE) demande à l'agent dans le chat de rechercher les comptes qui autorisent l'accès SSH depuis0.0.0.0/0. L'agent trouve un groupe de sécurité avec une règle d'entrée ouverte. Il recommande une solution d'atténuation : limitez la règle à la portée du réseau interne. L'opérateur demande à l'agent de l'appliquer.

Le même flux s'applique lorsque vous inspectez une enquête, un plan d'atténuation ou une recommandation d'amélioration et que vous demandez à l'agent d'exécuter une étape. L'agent transforme cette étape en une opération proposée spécifique et demande une approbation avant d'agir.

Le même flux s'applique aux outils tiers. Un opérateur triant le bruit d'alerte demande à l'agent d'augmenter le seuil d'une règle d'alerte Grafana. AWS DevOps L'agent classe cet outil comme mutant et l'équipe l'a activé pour un accès élevé lors de l'intégration. L'agent présente une demande d'approbation indiquant l'outil et les paramètres. Après approbation, l'agent invoque l'outil via l'intégration. AWS DevOps L'agent attribue l'action à l'opérateur approbateur.

Avant que les actions dirigées ne soient activées, ou qu'aucun rôle élevé n'ait été enregistré, l'agent poursuit ses recherches à l'aide d'actions en lecture seule. Il fournit des étapes de correction manuelles au lieu d'une modification exécutable.

Conditions préalables

Avant de pouvoir utiliser les actions dirigées, vous devez disposer des éléments suivants :

Activation des actions dirigées sur un espace d'agent

Les actions dirigées doivent être activées sur l'espace agent avant que toute autre configuration élevée ne prenne effet. Il s'agit du contrôle principal pour les actions dirigées. Si elle est désactivée, les enregistrements de rôles élevés et les opt-ins élevés pour les outils n'ont aucun effet. Les tentatives d'enregistrement d'une configuration élevée peuvent être rejetées.

Activation de dans la console

Activation via l'API

Vous activez les actions dirigées via l'espace agentpreferences. Ce champ est une carte dactylographiée des clés de préférence et des valeurs booléennes. Vous l'allumez CreateAgentSpace etUpdateAgentSpace.

L'exemple suivant active les actions dirigées à l'aide de l' AWS interface de ligne de commande.

aws devops-agent update-agent-space \
    --agent-space-id <your-agent-space-id> \
    --preferences elevatedActionsEnabled=true

Le preferences champ présente les comportements suivants :

Enregistrement d'un rôle élevé pour un AWS compte

Pour chaque AWS compte associé, vous pouvez éventuellement enregistrer un rôle élevé. Le compte moniteur et tous les comptes sources prennent chacun en charge un enregistrement de rôle élevé. Un rôle élevé est un rôle IAM dans votre compte que AWS DevOps l'agent assume pour effectuer des actions dirigées en votre nom. Vous enregistrez le rôle en agentElevatedRoleArn paramétrant la AWS configuration de l'association.

Lorsque vous enregistrez un rôle élevé, tenez compte des points suivants :

Rédaction de la politique de confiance

Le rôle élevé doit faire confiance au responsable du service de l' AWS DevOps agent. La validation applique la voie de l'assume-rôle. AWS DevOps L'agent utilise trois actions STS lorsqu'il assume le rôle. La politique de confiance doit autoriser les trois : sts:AssumeRolests:SetSourceIdentity, etsts:TagSession. Si vous omettez sts:SetSourceIdentity ousts:TagSession, les actions dirigées échouent au moment de l'identification, même lorsque le statut de validation est défini. valid

L'exemple suivant montre une politique de confiance pour un rôle élevé. 111122223333Remplacez-le par votre identifiant de AWS compte et us-east-1 par la AWS région de votre espace agent.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "aidevops.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "111122223333"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:aidevops:us-east-1:111122223333:agentspace/*"
        }
      }
    }
  ]
}

Les aws:SourceArn conditions aws:SourceAccount et protègent contre le problème confus des députés. Ils veillent à ce que le rôle ne puisse être assumé que pour le compte de vos propres espaces d'agents. La région dans la aws:SourceArn condition doit correspondre à la région de votre espace d'agent. Si vous gérez des espaces d'agent dans plusieurs régions, utilisez un caractère générique de région (arn:aws:aidevops:*:111122223333:agentspace/*) ou l'ARN de l'espace d'agent spécifique.

Octroi d'autorisations au rôle élevé

La politique d'autorisation du rôle élevé définit le plafond de ce que l' AWS DevOps agent peut faire sur votre compte par le biais d'actions dirigées. L'agent n'opère jamais à ce plafond. Chaque action dirigée nécessite l'approbation de l'opérateur. Les informations d'identification émises pour une action approuvée sont soumises à une politique de session. La politique de session les limite à l'opération et aux ressources spécifiques approuvées par l'opérateur. L'agent compose la politique de session uniquement à partir d'une liste organisée d'actions AWS IAM prises en charge par l'agent. AWS DevOps Une action en dehors de cette liste ne peut jamais faire partie d'une politique de session. Pour parcourir la liste, ouvrez la page Configuration dans la console de l' AWS DevOps agent. Choisissez Afficher les actions prises en charge dans la section Actions de l'agent. Deux options s'offrent à vous pour la politique d'autorisation.

Option 1 : attachez la politique AWS gérée. AWS DevOps L'agent fournit la politique AIDevOpsAgentActionsPolicy gérée. Son ARN est arn:aws:iam::aws:policy/AIDevOpsAgentActionsPolicy. Pour le document de politique au format code, consultez le AWS Managed Policy Reference Guide.

La politique gérée présente les caractéristiques suivantes :

Option 2 : Rédiger une politique gérée par le client. Si vous souhaitez un plafond plus strict que celui prévu par la politique gérée, rédigez votre propre politique. Élargissez-le aux actions et aux ressources que vous souhaitez que l'agent touche, et associez-le au rôle. Suivez le principe du moindre privilège : commencez par les opérations que vous attendez de la part des opérateurs, et développez-les uniquement si nécessaire. Les actions dirigées que le rôle n'autorise pas échouent au moment de l'exécution, même lorsqu'elles sont approuvées.

Quelle que soit l'option choisie, vous pouvez restreindre davantage ce que l'agent peut faire en utilisant des politiques de contrôle des services (SCP) et des limites d'autorisations. Ces contrôles s'appliquent au rôle élevé comme à tout autre rôle de votre compte. Pour plus d'informations sur la définition de la portée de l'accès de l'agent, consultezLimiter l'accès des agents dans un AWS Compte.

Cycle de vie de validation

Le mode de validation de la politique de confiance dépend du type de compte.

Le rôle n'est utilisé pour les actions dirigées qu'une fois son statut définivalid.

Pour les comptes sources, examinez l'association avec GetAssociation ou ListAssociations et cochez le agentElevatedRoleArnStatus champ. La validation se termine généralement en quelques minutes.

Opérations que l'agent n'effectuera pas

Quelles que soient les autorisations que vous accordez, l'agent applique ses propres mesures de protection aux opérations du AWS SDK qu'il invoque en tant qu'actions dirigées. Ces garde-fous ne s'appliquent qu'aux actions contre AWS des ressources. La classification des outils régit plutôt les outils tiers. Pour plus d'informations sur la classification des outils, consultez la section Catégorisation des outils pour les intégrations tierces. Ces garde-fous s'appliquent même lorsque la politique du rôle élevé autorise l'opération. L'approbation de l'opérateur ne les remplace pas.

Lorsqu'on lui demande d'effectuer l'une de ces opérations, l'agent refuse et explique pourquoi. Dans la mesure du possible, il décrit plutôt les étapes manuelles.

Ces garde-fous complètent les contrôles que vous possédez : la politique d'autorisation du rôle élevé, les SCP et les limites d'autorisations du rôle élevé.

Outils de catégorisation pour les intégrations tierces

Third-party et les intégrations MCP exposent les outils en trois catégories qui déterminent si l'agent peut invoquer l'outil et quelle approbation est requise. AWS DevOps L'agent attribue des classifications fixes pour les intégrations natives. Vous les attribuez aux serveurs MCP configurés par le client.

Customer-configured Serveurs MCP

Pour les associations de serveurs MCP (y compris la variante Sigv4), vous classez vous-même les outils à toolDetails l'aide d'une liste d'entrées par outil. Chaque entrée comporte un name et untoolClassification.

Pour plus d'informations sur la connexion et l'autorisation des outils MCP, consultez. Connexion de serveurs MCP

Intégrations natives (Datadog, Grafana)

Pour les intégrations natives telles que Datadog et Grafana, les classifications sont définies par l'Agent. AWS DevOps Vous ne fournissez pas de classifications. Vous ne pouvez pas modifier ces classifications. Au lieu de cela, vous choisissez des outils de mutation spécifiques enabledElevatedTools dans une liste d'entrées d'outils.

Approuver les actions dirigées

Les actions dirigées sont prises en compte par l'homme. Lorsque l'agent détermine qu'une opération qu'il a été chargé d'effectuer modifie une ressource, il n'exécute pas l'opération directement. Au lieu de cela, ce qui suit se produit :

AWS DevOps L'agent affiche les demandes d'approbation de l'opérateur uniquement dans le chat. Si l'agent invoque un outil mutant en dehors du chat, par exemple lors d'une enquête autonome, l'appel échoue au lieu de présenter une demande d'approbation. AWS DevOps L'agent n'exécute jamais un outil de mutation sans approbation.

Les approbations et les actions qui en résultent sont attribuables à l'opérateur qui les approuve. AWS CloudTrail

Le flux d'approbation dans l'API

N'importe quel client d'agents peut gérer ce flux de la même manière, qu'il s'agisse d'un assistant intelligent tel que Claude, d'un bot Slack ou d'un client d'opérations personnalisées : appelezSendMessage, soumettez la demande d'approbation à un opérateur, enregistrez la décision avec lui UpdateApprovalAction et reprenez la conversation avec SendMessage lui.

Surveillance et audit

Résolution des problèmes

Un rôle enregistré reste actifpending-confirmation. Cela s'applique aux comptes sources (secondaires), où la validation est asynchrone. La validation se termine normalement en quelques minutes. Si le statut ne change pas, vérifiez que le rôle existe et réenregistrez l'ARN du rôle pour déclencher à nouveau la validation.

Le statut du rôle estinvalid. La validation de la politique de confiance a échoué. Vérifiez que :

Corrigez la politique de confiance et réenregistrez le rôle.

Les actions dirigées échouent même si le statut du rôle est définivalid. Le valid statut reflète le contrôle de validation effectué au moment de l'inscription. Si la politique de confiance a été modifiée après validation, ou si sa aws:SourceArn condition est associée à une région différente de celle de l'espace agent, l'appel live assume-role peut toujours échouer. Passez en revue la politique de confiance par rapport à la liste de contrôle ci-dessus.

ValidationExceptionlors de l'enregistrement d'un rôle élevé. Les actions dirigées doivent être activées sur l'espace agent pour que vous puissiez enregistrer une configuration élevée. Activez d'abord les actions dirigées sur l'espace agent, puis enregistrez le rôle.

Erreurs de non-concordance entre les noms des outils lors de la fournituretoolDetails. Chaque nom saisi toolDetails doit correspondre exactement à un nom d'outil figurant dans la liste des outils activés de l'association, majuscules/minuscules comprises. Comparez les deux listes, corrigez les incohérences, puis réessayez.