View a markdown version of this page

Trabajando con acciones dirigidas - AWS DevOps Agente
Ejemplo: ejecutar un plan de mitigación a partir de una investigaciónRequisitos previosHabilitar las acciones dirigidas en un espacio de agentesRegistrar un rol elevado para un AWS inscritaOperaciones que el agente no realizaráHerramientas de categorización para integraciones de tercerosAprobar acciones dirigidasMonitoreo y auditoríaResolución de problemas

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Trabajando con acciones dirigidas

AWS DevOps El agente puede actuar en tus AWS cuentas y servicios conectados cuando un operador se lo pida explícitamente. Por ejemplo, un operador que investiga un incidente puede pedirle al agente que describa el estado de un recurso. Con los permisos y aprobaciones adecuados, el operador también puede pedirle al agente que solucione un problema directamente.

El agente distingue dos tipos de operaciones:

  • Read-only acciones: operaciones que solo leen la información de sus AWS cuentas y servicios conectados. Están disponibles de forma predeterminada.

  • Acciones dirigidas: operaciones que crean, modifican o mutan de otro modo los recursos. Las acciones dirigidas son elevadas: están deshabilitadas de forma predeterminada y requieren la autorización explícita por capas y la aprobación del operador por acción.

El modelo de seguridad para las acciones dirigidas es la defensa en profundidad. La capacidad está deshabilitada de forma predeterminada. La suscripción se realiza a través de capas independientes: habilita las acciones dirigidas en el espacio de los agentes, registra un rol de IAM por cuenta y clasifica cada herramienta. Cada acción dirigida requiere la aprobación del operador en el momento de la ejecución. Cada aprobación y acción resultante es atribuible al operador que la aprueba en AWS CloudTrail.

En el caso de las acciones contra AWS los recursos, el agente aplica sus propias barreras a las operaciones del AWS SDK que invoca, independientemente de los permisos que concedas. Para obtener más información sobre estas barreras, consulte Operaciones que el agente no realizará.

Ejemplo: ejecutar un plan de mitigación a partir de una investigación

Este ejemplo muestra la experiencia de principio a fin para un escenario común. Un operador revisa el plan de mitigación de una investigación o una recomendación de mejora. El operador le pide al agente que lo lleve a cabo sin abandonar la conversación.

Un ingeniero de confiabilidad del sitio (SRE) le pide al agente del chat que busque cualquier cuenta desde 0.0.0.0/0 la que se pueda acceder mediante SSH. El agente encuentra un grupo de seguridad con una regla de entrada abierta. Recomienda una mitigación: restringir la regla al alcance de la red interna. El operador le dice al agente que la aplique.

  1. El agente propone el cambio. El agente inspecciona el grupo de seguridad (una acción de solo lectura). Propone eliminar la 0.0.0.0/0 regla y añadir una regla que abarque el rango de la red interna. La propuesta identifica la operación exacta de la API, el grupo de seguridad objetivo, una evaluación de riesgos, el radio de explosión esperado y los pasos de retroceso.

  2. El operador revisa y aprueba. La operación muta un recurso, por lo que es una acción dirigida. La solicitud de aprobación muestra la operación y sus parámetros. El operador puede ajustar los parámetros, por ejemplo10.1.0.0/16, limitándolos 10.0.0.0/8 a la solicitud o rechazándola. No se ejecuta nada sin una aprobación explícita.

  3. El agente se ejecuta con credenciales específicas. El agente usa las credenciales del rol elevado registrado. Las credenciales se refieren a la operación y el recurso aprobados y son válidas durante un período limitado. La aprobación no se puede volver a utilizar para una operación o recurso diferente.

  4. La acción es totalmente auditable. La llamada aparece AWS CloudTrail con una identidad de origen que la atribuye al operador que la aprueba. CloudTrail registra los parámetros aprobados y ejecutados.

El mismo flujo se aplica cuando inspecciona cualquier investigación, plan de mitigación o recomendación de mejora y pide al agente que ejecute un paso. El agente convierte el paso en una operación propuesta específica y solicita su aprobación antes de actuar.

El mismo flujo se aplica a las herramientas de terceros. Un operador que clasifica el ruido de una alerta pide al agente que aumente el umbral de una regla de alerta de Grafana. AWS DevOps El agente clasifica esta herramienta como mutante y el equipo la habilitó para permitir un acceso elevado a la integración. El agente presenta una solicitud de aprobación en la que se muestran la herramienta y los parámetros. Tras la aprobación, el agente invoca la herramienta a través de la integración. AWS DevOps El agente atribuye la acción al operador que la aprueba.

Antes de habilitar las acciones dirigidas, o sin registrar un rol elevado, el agente sigue investigando con acciones de solo lectura. Proporciona pasos de corrección manuales en lugar de un cambio ejecutable.

Requisitos previos

Antes de poder usar las acciones dirigidas, necesita lo siguiente:

  • Un espacio de agente en AWS DevOps Agent con al menos una asociación a una AWS cuenta o una integración de terceros compatible.

  • Permisos para actualizar el espacio de agentes y sus asociaciones, por ejemplo, a través de la consola del AWS DevOps agente o la API.

  • Permisos en la cuenta de destino para crear un rol de IAM y definir sus políticas de confianza y permisos, para acciones dirigidas contra las AWS cuentas.

  • iam:PassRolepermiso arn:aws:iam::<account-id>:role/* en tu propia cuenta, con la clave de condición iam:PassedToService establecida enaidevops.amazonaws.com, para registrar el rol en la asociación. Una iam:PassRole subvención más amplia también satisface este requisito.

  • Acceso al espacio de agentes para los operadores que aprobarán las acciones dirigidas.

Habilitar las acciones dirigidas en un espacio de agentes

Las acciones dirigidas deben estar habilitadas en el espacio de agentes antes de que surta efecto cualquier otra configuración elevada. Este es el control principal de las acciones dirigidas. Si está deshabilitado, el número elevado de registros de funciones y el número elevado de opciones de uso de herramientas no surtirán efecto. Es posible que se rechacen los intentos de registrar una configuración elevada.

Habilitación de en la consola

  1. Abra la consola del AWS DevOps agente.

  2. Elige tu espacio de agente.

  3. Acceda a la configuración del espacio de agentes y habilite las acciones dirigidas.

  4. Confirme el cambio.

Habilitación a través de la API

Las acciones dirigidas se habilitan a través del espacio de agentespreferences. Este campo es un mapa mecanografiado de claves de preferencias para valores booleanos. Lo configuras en y. CreateAgentSpace UpdateAgentSpace

El siguiente ejemplo habilita las acciones dirigidas con la AWS CLI.

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

El preferences campo tiene los siguientes comportamientos:

  • preferencesSuppliing on UpdateAgentSpace reemplaza el conjunto completo, por lo que las preferencias omitidas vuelven a sus valores predeterminados.

  • La omisión del preferences campo deja los valores actuales sin cambios.

  • elevatedActionsEnabledLa configuración es opcional, porque la preferencia por defecto es. false

  • Se produce un error al proporcionar una clave de preferencia desconocida. ValidationException

  • El cambio de una preferencia tiene efecto inmediato y equivale a cambiar de consola.

  • Al llamar, se GetAgentSpace devuelve el preferences mapa actual, lo que confirma la configuración.

Registrar un rol elevado para un AWS inscrita

Para cada AWS cuenta asociada, si lo desea, puede registrar un rol elevado. Tanto la cuenta de monitor como cualquier cuenta de origen admiten un registro de roles elevado. Un rol elevado es un rol de IAM en su cuenta que el AWS DevOps agente asume para realizar acciones dirigidas en su nombre. Para registrar el rol, defina agentElevatedRoleArn la AWS configuración de la asociación.

Al registrar un rol elevado, tenga en cuenta lo siguiente:

  • El registro es opcional para cada cuenta. Si no registras un rol elevado para una cuenta, solo estarán disponibles las acciones de solo lectura para esa cuenta.

  • Recomendamos una convención de nomenclatura reconocible, por ejemplo, DevOpsAgent-ElevatedAction-* para que los roles elevados sean fáciles de auditar. El servicio no requiere un nombre específico.

  • La política de permisos del rol es administrada por el cliente. Limítela a las acciones que desea que el agente pueda realizar. La función define el límite máximo de lo que el agente puede hacer en tu cuenta. No es una subvención permanente. Además, cada acción dirigida requiere la aprobación del operador en el momento de la ejecución, y la sesión del agente depende además de la operación específica aprobada.

Redacción de la política de confianza

El rol elevado debe confiar en el AWS DevOps agente principal del servicio. La validación ejercita la ruta de asunción del rol. AWS DevOps El agente usa tres acciones de STS cuando asume la función. La política de confianza debe permitir las tres opciones: sts:AssumeRolests:SetSourceIdentity, ysts:TagSession. Si omites sts:SetSourceIdentity osts:TagSession, las acciones dirigidas fallan en el momento de la credencial, incluso cuando el estado de validación es. valid

El siguiente ejemplo muestra una política de confianza para un rol elevado. 111122223333Sustitúyala por tu ID de AWS cuenta y us-east-1 por la AWS región de tu espacio de agente.

{
  "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/*"
        }
      }
    }
  ]
}

Las aws:SourceArn condiciones aws:SourceAccount y las condiciones protegen contra el confuso problema de los diputados. Garantizan que el rol solo pueda asumirse en nombre de sus propios espacios de agentes. La región de la aws:SourceArn condición debe coincidir con la región de su espacio de agente. Si opera espacios de agentes en varias regiones, utilice un comodín de región (arn:aws:aidevops:*:111122223333:agentspace/*) o el ARN del espacio de agente específico.

Concesión de permisos al rol elevado

La política de permisos del rol elevado define el límite máximo de lo que el AWS DevOps agente puede hacer en su cuenta mediante acciones dirigidas. El agente nunca opera con este límite. Toda acción dirigida requiere la aprobación del operador. Las credenciales emitidas para una acción aprobada contienen una política de sesión. La política de sesión las abarca hasta la operación y los recursos específicos aprobados por el operador. El agente elabora la política de sesión únicamente a partir de una lista seleccionada de acciones de AWS IAM compatibles que AWS DevOps el agente mantiene. Una acción ajena a esa lista nunca puede formar parte de una política de sesión. Para explorar la lista, abra la página de configuración en la consola del AWS DevOps agente. Seleccione Ver acciones compatibles en la sección Acciones del agente. Tiene dos opciones para la política de permisos.

Opción 1: adjunte la política AWS gestionada. AWS DevOps El agente proporciona la política AIDevOpsAgentActionsPolicy gestionada. Su ARN es arn:aws:iam::aws:policy/AIDevOpsAgentActionsPolicy. Para ver el documento de política en formato de código, consulte la Guía de referencia de políticas AWS administradas.

La política gestionada tiene las siguientes características:

  • Otorga permisos amplios: todas las acciones, en todos los recursos. Excluye los servicios de administración de identidades, credenciales y organizaciones. Los servicios excluidos sonaccount:*,cognito-identity:*,iam:*,identitystore:*,organizations:*, ram:* rolesanywhere:*sso:*, y. sts:* Como resultado, el rol no puede administrar identidades ni obtener más acceso.

  • Permite realizar un pequeño conjunto de acciones de solo lectura desde esos servicios:account:GetAccountInformation,,account:GetGovCloudAccountInformation,account:GetPrimaryEmail,account:ListRegions, iam:ListRoles organizations:DescribeEffectivePolicyorganizations:DescribeOrganization, y. sts:DecodeAuthorizationMessage

  • Incluye acciones de eliminación de clases en el límite máximo. El propio agente rechaza las operaciones de eliminación de clases independientemente de los permisos del rol. Para obtener más información sobre las operaciones que el agente rechaza, consulte Operaciones que el agente no realizará.

  • La política define solo el límite máximo. Los permisos efectivos para cualquier acción individual se reducen en el momento de la ejecución a la operación aprobada.

Opción 2: Redactar una política gestionada por el cliente. Si desea un límite más ajustado que el que ofrece la póliza administrada, redacte su propia póliza. Defina exactamente las acciones y los recursos que desea que intervenga el agente y adjúntelo al rol. Siga el principio del mínimo privilegio: comience por las operaciones que espera que aprueben los operadores y amplíe solo cuando sea necesario. Las acciones dirigidas que el rol no permite fallan en el momento de la ejecución, incluso cuando se aprueban.

Con cualquiera de las opciones, puede restringir aún más lo que puede hacer el agente mediante las políticas de control de servicios (SCP) y los límites de permisos. Estos controles se aplican al rol elevado como a cualquier otro rol de su cuenta. Para obtener más información sobre el alcance del acceso del agente, consulteLimitar el acceso de los agentes en un AWS Cuenta.

Ciclo vital de validación

La forma en que se ejecuta la validación de las políticas de confianza depende del tipo de cuenta.

  • Supervise la cuenta (principal). La validación es sincrónica. AWS DevOps El agente valida el rol al guardarlo. El resultado estará disponible cuando la página se vuelva a cargar o cuando vuelva la llamada a la API. agentElevatedRoleArnStatusrefleja valid o invalid inmediatamente.

  • Cuentas de origen (secundarias). La validación es asincrónica. Después de registrar un rol elevado, ocurre lo siguiente:

    1. La asociación acepta inmediatamente el registro e informa agentElevatedRoleArnStatus como talpending-confirmation.

    2. AWS DevOps El agente valida la función siguiendo la ruta de asumir el rol.

    3. El estado pasa a valid si la validación se realiza correctamente o invalid si falla.

El rol se usa para acciones dirigidas solo después de que su estado seavalid.

En el caso de las cuentas de origen, sondea la asociación con GetAssociation o ListAssociations y comprueba el agentElevatedRoleArnStatus campo. La validación normalmente se completa en unos minutos.

Operaciones que el agente no realizará

Independientemente de los permisos que concedas, el agente aplica sus propias barreras a las operaciones del AWS SDK que invoca como acciones dirigidas. Estas barreras solo se aplican a las acciones contra los recursos. AWS En cambio, la clasificación de herramientas rige las herramientas de terceros. Para obtener más información sobre la clasificación de herramientas, consulta Cómo categorizar las herramientas para integraciones de terceros. Estas barreras se aplican incluso cuando la política del rol elevado permite la operación. La aprobación del operador no las anula.

  • Elimine los recursos. El agente rechaza las operaciones de eliminación de clases, por ejemplo, eliminar una instancia, un bucket, una tabla, una función o una pila. El propio operador elimina los recursos con sus propias credenciales.

  • Mute los límites de los permisos. El agente rechaza las operaciones que establecen o eliminan los límites de permisos de IAM:iam:PutRolePermissionsBoundary, iam:DeleteRolePermissionsBoundaryiam:PutUserPermissionsBoundary, yiam:DeleteUserPermissionsBoundary. Los límites son un control que la organización utiliza para restringir al agente, por lo que este no puede cambiarlos.

  • Exigiriam:PassRole. De forma predeterminada, el agente no admite operaciones que transfieran una función de IAM a un AWS servicio. Los ejemplos incluyen el lanzamiento de una instancia con un perfil de instancia o la creación de una función de Lambda con un rol de ejecución. Otro ejemplo es iniciar una tarea con un rol de tarea. Transferir un rol puede ampliar indirectamente lo que hace un servicio en tu nombre.

Cuando se le indica que realice una de estas operaciones, el agente se niega y explica por qué. Cuando puede, describe los pasos manuales en su lugar.

Estas barreras complementan los controles que posee: la política de permisos del rol elevado, los SCP y los límites de permisos del rol elevado.

Herramientas de categorización para integraciones de terceros

Third-party Las integraciones de MCP y MCP clasifican las herramientas en tres categorías que determinan si el agente puede invocar la herramienta y qué aprobación se requiere. AWS DevOps El agente asigna clasificaciones fijas a las integraciones nativas. Las asigna a los servidores MCP configurados por el cliente.

Clasificación Significado Comportamiento
READ_ONLY La herramienta solo lee información. Disponible como acción de solo lectura.
MUTATIVE La herramienta puede crear o modificar recursos. Requiere que las acciones dirigidas estén activadas y la aprobación del operador por acción en el chat.
DESTRUCTIVE La herramienta puede eliminar o cambiar los recursos de forma irreversible. El agente nunca invoca las herramientas de esta clasificación.

Customer-configured Servidores MCP

En el caso de las asociaciones de servidores MCP (incluida la variante Sigv4), usted mismo clasifica las herramientas mediante toolDetails una lista de entradas por herramienta. Cada entrada tiene una y unaname. toolClassification

  • Cada una name debe coincidir exactamente con una entrada de la lista de herramientas habilitadas de la asociación. Las discrepancias se rechazan en el momento del registro.

  • Las herramientas sin una clasificación almacenada tienen el valor predeterminado. READ_ONLY Si registra o actualiza una asociación de servidores MCP mediante programación, mediante un AWS SDK, la AWS CLI o una llamada directa a la API, y no la suministratoolDetails, el AWS DevOps Agente trata todas las herramientas de esa asociación como tal. READ_ONLY El agente ejecuta herramientas de solo lectura sin solicitar su aprobación. Para solicitar la aprobación del operador antes de ejecutar una herramienta que crea o modifica recursos, clasifíquela explícitamente como. MUTATIVE La consola le pide que clasifique cada herramienta descubierta. Las personas que llaman mediante programación deben configurarse por sí mismas. toolDetails

  • Los nombres de las herramientas tienen entre 1 y 128 caracteres. Puede clasificar hasta 500 herramientas por asociación.

Para obtener más información sobre cómo conectar y permitir la creación de herramientas de MCP, consulte. Conexión de servidores MCP

Integraciones nativas (Datadog, Grafana)

En el caso de las integraciones nativas, como Datadog y Grafana, el agente fija las clasificaciones. AWS DevOps No se proporcionan clasificaciones. No puede anular estas clasificaciones. En su lugar, puede incluir herramientas de mutación específicas mediante enabledElevatedTools una lista de entradas de herramientas.

  • Solo se MUTATIVE pueden habilitar las herramientas según las cuales el AWS DevOps Agente clasifique.

  • Las herramientas clasificadas como DESTRUCTIVE (por ejemplo,grafana_delete_alert_rule) nunca se pueden habilitar.

Aprobar acciones dirigidas

Las acciones dirigidas son humanas en sintonía. Cuando el agente determina que una operación que se le ha ordenado que realice muta un recurso, no ejecuta la operación directamente. En su lugar, ocurre lo siguiente:

  1. El agente solicita la aprobación y presenta al operador la herramienta, la operación y el recurso objetivo específicos.

  2. El operador revisa la solicitud y la aprueba o rechaza.

  3. Si se aprueba, el agente realiza la operación. Cada aprobación cubre solo la herramienta, la operación y el recurso específicos solicitados. Sigue siendo válida durante un período de tiempo limitado y no se puede reutilizar para una operación o recurso diferente.

AWS DevOps El agente muestra las solicitudes de aprobación del operador solo en el chat. Si el agente invoca una herramienta de mutación fuera del chat, por ejemplo, durante una investigación autónoma, la llamada falla en lugar de presentar una solicitud de aprobación. AWS DevOps El agente nunca ejecuta una herramienta de mutación sin su aprobación.

Las aprobaciones y las acciones resultantes son atribuibles al operador que las aprueba en. AWS CloudTrail

El flujo de aprobación en la API

  • SendMessagetransmite una solicitud de aprobación. La solicitud identifica la herramienta, la operación y el recurso de destino, con identificadores de interrupción para la reanudación. Como ejemplo práctico, supongamos que un operador trabaja en un asistente de IA como Claude. El operador le pide que purgue la cola de mensajes fallidos. arn:aws:sqs:us-east-1:111122223333:my-app-dlq Claude llama SendMessage al AWS DevOps agente y el flujo de respuestas incluye una solicitud de aprobación que identifica la herramientause_aws, la operación y el ARN de la colasqs:PurgeQueue, junto con, y los identificadores. toolUseId interruptId approvalId

  • El operador registra la decisión con. UpdateApprovalAction El operador la aprueba con un alcance definido o la rechaza con un motivo opcional. Aquí, Claude muestra la solicitud al operador action: APPROVED y, a continuación, llama UpdateApprovalAction con una finalPattern herramientause_aws, argumentPins fijando operation en sqs:PurgeQueue y en el ARN de resource_arn la cola.

  • El alcance final puede reducir la solicitud, pero nunca ampliarla.

  • El operador marca una aprobación de un solo uso o establece un período de reutilización de hasta 4 horas. La eliminación de colas es una operación que se realiza una sola vez, por lo que el operador marca esta aprobación como de un solo uso (singleUse: true, no). ttlSeconds

  • El cliente reanuda la conversación pausada llamando de SendMessage nuevo con la decisión adjunta. En este ejemplo, Claude establece userActionResponse APPROVAL_ACTION y approvalAction suministra la decisión toolUseIdinterruptId,approvalId, y. APPROVED AWS DevOps A continuación, el agente purga la cola.

  • El ciclo de aprobación esPENDING, entonces, APPROVED (canjeable) o REJECTED (terminal). APPROVEDLa aprobación se obtiene REDEEMED después de que se consume y puede hacerse REVOKED antes de su uso. En este caso, la solicitud es PENDING mientras el operador decide, APPROVED después de la decisión y REDEEMED después de que el agente purgue la cola.

Cualquier agente consumidor puede gestionar este flujo de la misma manera, ya sea un asistente de inteligencia artificial como Claude, un bot de Slack o un cliente de operaciones personalizadas: llameSendMessage, envíe la solicitud de aprobación a un operador, registre la decisión y reanude la UpdateApprovalAction conversación con él. SendMessage

Monitoreo y auditoría

  • Estado de validación de funciones: monitoriza agentElevatedRoleArnStatus tus AWS asociaciones (a través de GetAssociation oListAssociations) para confirmar que las funciones de categoría superior permanecen en el valid estado.

  • AWS CloudTrail— Las acciones dirigidas que se realizan en tus AWS cuentas aparecen en CloudTrail. La sesión en la que se asume el rol incluye una identidad de origen que atribuye la acción al operador que la aprobó. Puedes rastrear cada acción dirigida hasta la persona que la aprobó.

Resolución de problemas

Un rol registrado permanece activopending-confirmation. Esto se aplica a las cuentas de origen (secundarias), donde la validación es asincrónica. La validación normalmente se completa en unos minutos. Si el estado no cambia, compruebe que el rol existe y vuelva a registrar el ARN del rol para volver a activar la validación.

El estado del rol es. invalid La validación de la política de confianza falló. Compruebe que:

  • La política de confianza nombra al principal del servicio del AWS DevOps agente.

  • La política de confianza permite todas las acciones STS necesarias (sts:AssumeRolests:SetSourceIdentity,, ysts:TagSession), no solosts:AssumeRole.

  • La aws:SourceAccount condición coincide con la cuenta propietaria del espacio de agente.

  • La región de la aws:SourceArn condición coincide con la región del espacio de agentes (o usa un comodín de región).

Corrija la política de confianza y vuelva a registrar el rol.

Las acciones dirigidas fallan aunque el estado del rol seavalid. El valid estado refleja la comprobación de validación en el momento del registro. Si la política de confianza se modificó después de la validación, o si su aws:SourceArn estado está vinculado a una región distinta a la del espacio del agente, la llamada en vivo para asumir un rol aún puede fallar. Revisa la política de confianza comparándola con la lista de verificación anterior.

ValidationExceptional registrar un rol elevado. Las acciones dirigidas deben estar habilitadas en el espacio de agentes antes de poder registrar la configuración elevada. Primero habilite las acciones dirigidas en el espacio de agentes y, a continuación, registre el rol.

Errores de discordancia en el nombre de la herramienta al suministrarlatoolDetails. Cada nombre toolDetails debe coincidir exactamente con el nombre de una herramienta de la lista de herramientas habilitadas de la asociación, incluidas las mayúsculas y minúsculas. Compare las dos listas, corrija cualquier discrepancia y vuelva a intentarlo.