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.

Políticas temporales

La política de Amazon Bedrock AgentCore es compatible con las políticas temporales: políticas cuyas decisiones dependen del historial de las acciones de un agente en una sesión, no solo de la solicitud actual. Con ellas, puede aplicar reglas que abarquen varias acciones, como solicitar una aprobación antes de realizar una acción, limitar el número de veces que se ejecuta una acción en un intervalo de tiempo o mantener el total acumulado por debajo de un umbral.

Una política temporal es una forbid regla permit o que contiene uno o más operadores temporales. Cada condición coincide con un evento anterior registrado para la sesión según sus campos de acción, principal y de entrada o salida de la acción, y solo considera los eventos dentro de un período de tiempo requerido. Una condición puede correlacionar un evento coincidente con la solicitud actual, por lo que una regla puede exigir, por ejemplo, que la solicitud actual actúe sobre un recurso que ya haya sido aprobado por una acción anterior. El motor de políticas registra los eventos de cada sesión y evalúa estas condiciones en cada solicitud, por lo que las reglas que se adaptan a las sesiones se expresan como políticas, en lugar de hacer un seguimiento de los eventos en el código de agente o herramienta.

Las políticas temporales están escritas en Dogwood, que es compatible con Cedar y respalda todas las políticas de Cedar existentes. Las políticas estándar de Cedar son apátridas y solo consideran la solicitud actual. Las políticas temporales siguen el mismo modelo de denegación por defecto: solo se permite una solicitud cuando se permit aplica una y no se anula. forbid Las condiciones temporales son distintas de las basadas en el tiempo, que restringen el acceso en función de la hora () context.system.now del reloj de pared y no del historial de la sesión. También puede ejecutar una política temporal en LOG_ONLY modo para observar lo que decidiría antes de promocionarlaENFORCE; consulte Modos de aplicación de políticas.

Conceptos clave

Las políticas temporales se basan en dos elementos: el lenguaje normativo de Dogwood, que expresa las reglas que se adaptan a las sesiones, y la sesión de políticas, que abarca el historial que puede ver una regla.

El lenguaje político de Dogwood

Las políticas temporales están escritas en Dogwood, un lenguaje de políticas de código abierto que Policy in AgentCore utiliza para la autorización con reconocimiento de sesiones. Dogwood se basa en Cedar y usa el mismo modelo de autorización: tú escribes permit y forbid gobiernas un principal, una acción y un recurso, y solo se permite una solicitud cuando se permit aplica una y no la anula. forbid Dogwood es compatible con Cedar y es compatible con todas las políticas de Cedar existentes, por lo que cada política de Cedar válida también es una política de Dogwood válida. Tus políticas actuales sobre un determinado momento siguen funcionando sin cambios, y solo añades condiciones temporales cuando una regla debe tener en cuenta más que la solicitud actual.

Con Dogwood, las reglas que se adaptan a las sesiones se expresan de forma declarativa en forma de políticas, en lugar de implementar la lógica de seguimiento de eventos en el código de su agente o herramienta. El motor de políticas registra los eventos relevantes y evalúa el estado de cada solicitud. Por ejemplo, la siguiente política permite una venta solo cuando se ha producido una aprobación correspondiente dentro de la hora anterior:

permit (
    principal,
    action == AgentCore::Action::"TradingTarget___SellShares",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 1h AgentCore::Action::"TradingTarget___ApproveSale"::response{
        eventResource:   resource,
        input.stock:     context.input.stock,
        input.shares:    context.input.shares,
        output.approved: true
    }
};

Dogwood proporciona operadores temporales para los patrones más comunes: formerly within (se produjo un evento coincidente al principio de la ventana), since within (se ha mantenido una condición desde un evento principal) y las agregaciones count y sum superaciones de los eventos coincidentes de la ventana.

Para ver la sintaxis temporal completa, consulta la guía lingüística de Dogwood en el sitio web de Dogwood Policy.

Las sesiones de políticas y el identificador de sesión

Las políticas temporales se evalúan en función de una sesión de políticas: una secuencia de invocaciones de Gateway relacionadas agrupadas en un identificador de sesión. El historial temporal depende de la sesión, por lo que una condición solo tiene en cuenta los eventos registrados en la misma sesión en la que se autorizó la solicitud. El identificador de sesión se genera y se envía en cada solicitud del x-amzn-bedrock-agentcore-policy-session-id encabezado, empezando por la primera solicitud. The Gateway no genera un identificador de sesión en su nombre. Si omite el encabezado o envía un valor vacío, el Gateway no establece una sesión. Si el motor de políticas asociado contiene una política temporal, las solicitudes sin un identificador de sesión fallan y se produce un error de validación.

Para obtener más información sobre cómo transferir el identificador de sesión, el ciclo de vida de la sesión y cómo se propaga la identidad en las llamadas de varios saltos, consulte Sesiones de políticas y propagación de identidades.

Invalidación de la sesión

Una política temporal decide si permite una acción analizando lo que ocurrió anteriormente en la misma sesión. Esa historia solo tiene sentido en comparación con las políticas temporales que estaban en vigor cuando comenzó la sesión. Si cambias las políticas temporales del motor mientras hay una sesión abierta, el historial registrado ya no coincide con las reglas actuales, por lo que el servicio finaliza la sesión en lugar de tomar una decisión en caso de que no haya datos incoherentes.

Agregar o actualizar una política temporal en el motor invalida las sesiones de políticas temporales activas del motor. Tras este cambio, la siguiente solicitud que reutilice una sesión invalidada produce un error con un HTTP 409. ConflictException

Para recuperarla, inicie una nueva sesión y vuelva a enviar la solicitud. La nueva sesión comienza con un historial vacío y se evalúa en función de las políticas actualizadas.

compatible AWS Regions

Las políticas temporales están disponibles en las AWS regiones marcadas en la tabla siguiente.

Consideraciones

Cross-account y solicitudes interregionales

Las sesiones de políticas temporales no admiten la propagación entre regiones o entre cuentas. Las políticas temporales no controlan las solicitudes entre las AgentCore puertas de enlace y sus destinos de tiempo de ejecución cuando esos recursos residen en cuentas o regiones diferentes. AWS Para que las políticas temporales controlen las acciones de su agente, la puerta de enlace y todos sus objetivos deben residir en la misma AWS cuenta y AWS región.

Las políticas temporales exigen el acceso solo cuando el token de acceso a la carga de trabajo (WAT) recorre la cadena de solicitudes (consulte Sesiones de políticas y propagación de identidades). Si la cadena de solicitudes está compuesta exclusivamente por componentes AgentCore Gateway y Runtime, AgentCore propaga el encabezado del WAT automáticamente de un salto al siguiente. Esta propagación se produce dentro de una sola AWS región y cuenta. Las políticas temporales se aplican en toda la cadena. Una cadena como Gateway to Runtime to Gateway to Runtime lleva el token de principio a fin, sin que tengas que hacer nada más.

Las cadenas que incluyen componentes que no son de Gateway o Runtime se comportan de forma diferente. Una solicitud puede pasar por una infraestructura que gestiones tú mismo, como una puerta de enlace de API de terceros o un clúster de Kubernetes. Ese componente debe reenviar el encabezado del WAT y tú debes agregar una lógica personalizada para propagar el WAT a través de esos saltos. La ubicación física de los elementos que no son AgentCore componentes no afecta al alcance regional y de la cuenta. Pueden ejecutarse en cualquier lugar, siempre que los AgentCore componentes de ambos lados regresen a la misma AWS cuenta y AWS región en las que se aplican las políticas temporales.

Permisos de IAM necesarios

Las políticas temporales también conllevan un requisito previo de IAM. La función de IAM configurada para la puerta de enlace debe permitir la bedrock-agentcore:GetWorkloadAccessToken acción. Este requisito se mantiene incluso cuando usas IAM para tu autorización saliente. El WAT permite que las políticas temporales correlacionen las acciones de un agente en una sesión. El Gateway debe poder obtener el WAT independientemente de cómo autentique las llamadas salientes. Si el rol no tiene este permiso, se produce un error en la aplicación de la política temporal. bedrock-agentcore:GetWorkloadAccessTokenOtorgue el rol de puerta de enlace al configurar las políticas temporales. Para ver la política de permisos completa, incluidos los ARN de los recursos y el alcance del directorio de identidades de carga de trabajo, consulte los permisos de IAM para las políticas temporales.

Self-referential las condiciones incluyen la solicitud actual

Cuando una condición temporal hace referencia a la misma acción que se está autorizando, el propio evento de la solicitud actual se incluye en la evaluación. Por ejemplo, una condición que cuenta el número de veces que se ha producido una acción en una ventana también cuenta la invocación actual.

Se debe permitir que una acción anterior se registre como respuesta

El historial de la sesión registra cada acción como un evento cuyo tipo refleja el resultado: una acción permitida que se completa se registra como un response evento y una acción que una política deniega se registra como un error evento. Una condición temporal solo coincide con los eventos del tipo que nombra, por lo que una condición que coincide con un response evento solo considera las acciones anteriores que estaban permitidas. Asegúrese de que la acción anterior en la que se basa una política temporal esté a su vez permitida por una política; si se deniega, se registra como una acción error en lugar de como unaresponse, y una response condición nunca la cumple.

Secuenciar las acciones que dependen de una respuesta previa

El historial de la sesión registra el response evento de cada acción una vez que se completa la acción. Cuando una política depende de la respuesta de una acción anterior en la misma sesión, como un campo de salida o una since condición, emita la solicitud dependiente después de recibir la respuesta de la acción anterior. Al completar cada acción antes de iniciar la que depende de ella, la secuencia del flujo de trabajo se mantiene alineada con el historial que evalúa la política.

Cuotas

Las siguientes cuotas se aplican a las políticas temporales:

Observabilidad

Amazon Bedrock AgentCore publica métricas y datos de intervalos que le permiten observar la evaluación temporal de las políticas. Las métricas se publican en el espacio de AWS/Bedrock-AgentCore CloudWatch nombres de forma predeterminada. Los datos de intervalo pasan a estar disponibles después de habilitar el seguimiento del recurso de AgentCore Gateway adjunto y se encuentran en el grupo de CloudWatch aws/spans registros.

Las siguientes señales son específicas de las políticas temporales:

Para obtener la lista completa de las métricas, las dimensiones y los atributos de intervalo de las políticas, y para saber cómo habilitar la observabilidad, consulte la política en los datos de observabilidad. AgentCore

Consideraciones de seguridad

La limitación de velocidad con políticas temporales se aplica en una sola sesión. Como el historial temporal abarca una sesión y la persona que llama proporciona el identificador de la sesión, un límite count basado en «como máximo N llamadas por sesión» solo cuenta los eventos registrados para esa sesión. Al iniciar una nueva sesión, se inicia un nuevo recuento, por lo que un límite de frecuencia temporal restringe la actividad dentro de una sesión y no en todas las sesiones de la persona que llama.