Uso de las condiciones IAM de la política en Amazon EventBridge - Amazon EventBridge

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.

Uso de las condiciones IAM de la política en Amazon EventBridge

Para conceder permisos, se utiliza el lenguaje de la IAM política en una declaración de política para especificar las condiciones en las que una política debe entrar en vigor. Por ejemplo, puede tener una política que solo se aplique después de una fecha específica.

Una condición de una política consta de pares clave-valor. Las claves de condición no distinguen entre mayúsculas y minúsculas.

Si especificas varias condiciones o claves en una sola condición, se deben cumplir todas las condiciones y claves EventBridge para conceder el permiso. Si especificas una sola condición con varios valores para una clave, EventBridge concede el permiso si se cumple uno de los valores.

También puede utilizar marcadores de posición o variables de políticas al especificar condiciones. Para obtener más información, consulte Variables de política en la Guía del IAM usuario. Para obtener más información sobre la especificación de condiciones en un lenguaje IAM de políticas, consulte Condición en la Guía del IAM usuario.

De forma predeterminada, IAM los usuarios y los roles no pueden acceder a los eventos de tu cuenta. Para acceder a los eventos, un usuario debe estar autorizado para realizar la PutRule API acción. Si un IAM usuario o un rol están autorizados para realizar la events:PutRule acción, pueden crear una regla que coincida con determinados eventos. Sin embargo, para que la regla sea útil, el usuario también debe tener permisos para la events:PutTargets acción, ya que, si desea que la regla sirva para algo más que publicar una CloudWatch métrica, también debe añadir un objetivo a la regla.

Puede proporcionar una condición en la declaración de política de un IAM usuario o rol que permita al usuario o rol crear una regla que solo coincida con un conjunto específico de fuentes y tipos de eventos. Para conceder acceso a orígenes y tipos de eventos específicos, utilice las claves de condición events:source y events:detail-type.

Del mismo modo, puede incluir una condición en la declaración de política de un IAM usuario o rol que permita al usuario o rol crear una regla que solo coincida con un recurso específico de sus cuentas. Para conceder acceso a un recurso específico, utilice la clave de condición events:TargetArn.

El siguiente ejemplo es una política que permite a los usuarios acceder a todos los eventos, excepto a los EC2 eventos de Amazon, EventBridge mediante una declaración de rechazo en la PutRule API acción.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPutRuleForAllEC2Events", "Effect": "Deny", "Action": "events:PutRule", "Resource": "*", "Condition": { "StringEquals": { "events:source": "aws.ec2" } } } ] }

EventBridge claves de condición

En la siguiente tabla se muestran las claves de condición y los pares de claves y valores que se pueden utilizar en una política EventBridge.

Clave de condición Par clave-valor Tipos de evaluación

leyes: SourceAccount

La cuenta en la que reside la regla especificada por aws:SourceArn.

ID de cuenta, Null

leyes: SourceArn

El ARN de la regla que envía el evento.

ARN, Nulo

eventos: creatorAccount

"events:creatorAccount":"creatorAccount"

En creatorAccount, utilice el ID de cuenta de la cuenta que creó la regla. Usa esta condición para autorizar las API llamadas a las reglas desde una cuenta específica.

creatorAccount, Nulo

events:detail-type

"events:detail-type":"detail-type "

Donde detail-type es la cadena literal del campo de tipo detalle del evento, como "AWS API Call via CloudTrail" y. "EC2 Instance State-change Notification"

Tipo de detalle, Null

eventos: detalle. eventTypeCode

"events:detail.eventTypeCode":"eventTypeCode"

En eventTypeCode, utilice la cadena literal para el detalle. eventTypeCodecampo del evento, como"AWS_ABUSE_DOS_REPORT".

eventTypeCode, Nulo

events: detail.service

"events:detail.service":"service"

En service, utilice la cadena literal para el campo detail.service del evento, por ejemplo. "ABUSE"

servicio, Null

eventos: detalle. userIdentity. principalId

"events:detail.userIdentity.principalId":"principal-id"

En principal-id, utilice la cadena literal para el detalle. userIdentity. principalIdcampo del evento con un tipo de detalle"AWS API Call via CloudTrail", como. "AROAIDPPEZS35WEXAMPLE:AssumedRoleSessionName."

ID de entidad principal, Null

eventos: eventBusInvocation

"events:eventBusInvocation":"boolean"

En boolean, utilice true cuando una regla envíe un evento a un objetivo que sea un bus de eventos de otra cuenta. Use false cuando se utilice una PutEvents API llamada.

eventBusInvocation, Nulo

eventos: ManagedBy

Utilizado internamente por AWS los servicios. En el caso de una regla creada por un AWS servicio en su nombre, el valor es el nombre principal del servicio que creó la regla.

No está diseñado para su uso en las políticas de clientes.

events:source

"events:source":"source "

Uso source para la cadena literal del campo de origen del evento, como "aws.ec2" o"aws.s3". Para ver más valores posibles para source, consulte los eventos de ejemplo enEventos de AWS los servicios de Amazon EventBridge.

Origen, Null

eventos: TargetArn

"events:TargetArn":"target-arn "

En target-arn, utilice el ARN del objetivo para la regla, por ejemplo"arn:aws:lambda:*:*:function:*".

ArrayOfARN, Nulo

Para ver, por ejemplo, las declaraciones de política correspondientes a EventBridge, consulteAdministrar los permisos de acceso a tus EventBridge recursos de Amazon.

EventBridge Características específicas de las tuberías

EventBridge Pipes no admite ninguna clave de condición adicional IAM de la política.

Ejemplo: Uso de la condición creatorAccount

En el siguiente ejemplo de instrucción de política se muestra cómo utilizar la condición creatorAccount en una política para permitir la creación de reglas únicamente si la cuenta especificada como creatorAccount es la cuenta que creó la regla.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutRuleForOwnedRules", "Effect": "Allow", "Action": "events:PutRule", "Resource": "*", "Condition": { "StringEqualsIfExists": { "events:creatorAccount": "${aws:PrincipalAccount}" } } } ] }

Ejemplo: Uso de la condición eventBusInvocation

eventBusInvocationIndica si la invocación se origina en un objetivo multicuenta o en una solicitud. PutEvents API El valor es true cuando la invocación es el resultado de una regla que incluye un destino entre cuentas, como cuando el destino es un bus de eventos de otra cuenta. El valor es falso cuando la invocación es el resultado de una solicitud. PutEvents API El siguiente ejemplo indica una invocación desde un destino entre cuentas.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCrossAccountInvocationEventsOnly", "Effect": "Allow", "Action": "events:PutEvents", "Resource": "*", "Condition": { "BoolIfExists": { "events:eventBusInvocation": "true" } } } ] }

Ejemplo: Limitación del acceso a un origen específico

Los siguientes ejemplos de políticas se pueden adjuntar a un IAM usuario. La política A permite la PutRule API acción para todos los eventos, mientras que la política B PutRule solo lo permite si el patrón de eventos de la regla que se está creando coincide con EC2 los eventos de Amazon.

Política A: permitir todos los eventos

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutRuleForAllEvents", "Effect": "Allow", "Action": "events:PutRule", "Resource": "*" } ] }

Política B: —permitir eventos solo de Amazon EC2

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutRuleForAllEC2Events", "Effect": "Allow", "Action": "events:PutRule", "Resource": "*", "Condition": { "StringEquals": { "events:source": "aws.ec2" } } } ] }

EventPattern es un argumento obligatorio para PutRule. Por lo tanto, si el usuario con la Política B llama a PutRule con un patrón de eventos como el siguiente:

{ "source": [ "aws.ec2" ] }

La regla se crearía porque la política permite este origen específico, es decir, "aws.ec2". Sin embargo, si el usuario con la Política B llama a PutRule con un patrón de eventos como el siguiente, la creación de la regla se denegaría porque la política no permite este origen específico: es decir, "aws.s3".

{ "source": [ "aws.s3" ] }

Básicamente, el usuario con la Política B solo puede crear una regla que coincida con los eventos originados en AmazonEC2; por lo tanto, solo puede acceder a los eventos de AmazonEC2.

Consulte la tabla siguiente para una comparación de Política A y Política B.

Patrón de eventos Permitidos por la Política A Permitidos por la Política B
{ "source": [ "aws.ec2" ] }

{ "source": [ "aws.ec2", "aws.s3" ] }

No (el origen aws.s3 no está permitido)

{ "source": [ "aws.ec2" ], "detail-type": [ "EC2 Instance State-change Notification" ] }

{ "detail-type": [ "EC2 Instance State-change Notification" ] }

No (el origen debe especificarse)

Ejemplo: Definición de varios orígenes que puedan utilizarse en un patrón de eventos individualmente

La siguiente política permite a un IAM usuario o rol crear una regla en la que la fuente EventPattern sea Amazon EC2 o AmazonECS.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutRuleIfSourceIsEC2OrECS", "Effect": "Allow", "Action": "events:PutRule", "Resource": "*", "Condition": { "StringEquals": { "events:source": [ "aws.ec2", "aws.ecs" ] } } } ] }

En la tabla siguiente se ofrecen ejemplos de patrones de eventos que esta política permite o deniega.

Patrón de eventos Permitidos por la política
{ "source": [ "aws.ec2" ] }

{ "source": [ "aws.ecs" ] }

{ "source": [ "aws.s3" ] }

No

{ "source": [ "aws.ec2", "aws.ecs" ] }

No

{ "detail-type": [ "AWS API Call via CloudTrail" ] }

No

Ejemplo: Definición de un origen y un DetailType que puedan utilizarse en un patrón de eventos

La siguiente política permite eventos solo desde el origen aws.ec2 con DetailType igual a EC2 instance state change notification.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutRuleIfSourceIsEC2AndDetailTypeIsInstanceStateChangeNotification", "Effect": "Allow", "Action": "events:PutRule", "Resource": "*", "Condition": { "StringEquals": { "events:source": "aws.ec2", "events:detail-type": "EC2 Instance State-change Notification" } } } ] }

En la tabla siguiente se ofrecen ejemplos de patrones de eventos que esta política permite o deniega.

Patrón de eventos Permitidos por la política
{ "source": [ "aws.ec2" ] }

No

{ "source": [ "aws.ecs" ] }

No

{ "source": [ "aws.ec2" ], "detail-type": [ "EC2 Instance State-change Notification" ] }

{ "source": [ "aws.ec2" ], "detail-type": [ "EC2 Instance Health Failed" ] }

No

{ "detail-type": [ "EC2 Instance State-change Notification" ] }

No

Ejemplo: Comprobación de que el origen se ha definido en el patrón de eventos

La siguiente política permite a los usuarios crear reglas con EventPatterns que tienen el campo de origen. Con esta política, un IAM usuario o rol no puede crear una regla con una EventPattern que no proporcione una fuente específica.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutRuleIfSourceIsSpecified", "Effect": "Allow", "Action": "events:PutRule", "Resource": "*", "Condition": { "Null": { "events:source": "false" } } } ] }

En la tabla siguiente se ofrecen ejemplos de patrones de eventos que esta política permite o deniega.

Patrón de eventos Permitidos por la Política
{ "source": [ "aws.ec2" ], "detail-type": [ "EC2 Instance State-change Notification" ] }

{ "source": [ "aws.ecs", "aws.ec2" ] }

{ "detail-type": [ "EC2 Instance State-change Notification" ] }

No

Ejemplo: Definición de una lista de orígenes permitidos en un patrón de eventos con varios orígenes

La siguiente política permite a los usuarios crear reglas con EventPatterns que puede tener varios orígenes en ellas. Cada origen del patrón de eventos debe ser miembro de la lista proporcionada en la condición. Cuando utilice la condición ForAllValues, asegúrese de que al menos uno de los elementos de la lista de condiciones esté definido.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutRuleIfSourceIsSpecifiedAndIsEitherS3OrEC2OrBoth", "Effect": "Allow", "Action": "events:PutRule", "Resource": "*", "Condition": { "ForAllValues:StringEquals": { "events:source": [ "aws.ec2", "aws.s3" ] }, "Null": { "events:source": "false" } } } ] }

En la tabla siguiente se ofrecen ejemplos de patrones de eventos que esta política permite o deniega.

Patrón de eventos Permitidos por la Política
{ "source": [ "aws.ec2" ] }

{ "source": [ "aws.ec2", "aws.s3" ] }

{ "source": [ "aws.ec2", "aws.autoscaling" ] }

No

{ "detail-type": [ "EC2 Instance State-change Notification" ] }

No

Ejemplo: Limitación del acceso a PutRule mediante detail.service

Puedes restringir a un IAM usuario o rol la creación de reglas solo para los eventos que tengan un valor determinado en el events:details.service campo. El valor de events:details.service no es necesariamente el nombre de un AWS servicio.

Esta condición de política es útil cuando se trabaja con eventos relacionados con la seguridad o el abuso. AWS Health Al utilizar esta condición de política, puede limitar el acceso a estas alertas sensibles únicamente a aquellos usuarios que necesiten verlas.

Por ejemplo, la siguiente política permite la creación de reglas solo para los eventos cuyo donde el valor de events:details.service sea ABUSE.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutRuleEventsWithDetailServiceEC2", "Effect": "Allow", "Action": "events:PutRule", "Resource": "*", "Condition": { "StringEquals": { "events:detail.service": "ABUSE" } } } ] }

Ejemplo: Limitación del acceso a PutRule mediante detail.eventTypeCode

Puede restringir a un IAM usuario o rol la creación de reglas únicamente para los eventos que tengan un valor determinado en el events:details.eventTypeCode campo. Esta condición de política resulta útil cuando se trabaja con eventos relacionados con la seguridad o el abuso. AWS Health Al utilizar esta condición de política, puede limitar el acceso a estas alertas sensibles únicamente a aquellos usuarios que necesiten verlas.

Por ejemplo, la siguiente política permite la creación de reglas solo para los eventos cuyo donde el valor de events:details.eventTypeCode sea AWS_ABUSE_DOS_REPORT.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutRuleEventsWithDetailServiceEC2", "Effect": "Allow", "Action": "events:PutRule", "Resource": "*", "Condition": { "StringEquals": { "events:detail.eventTypeCode": "AWS_ABUSE_DOS_REPORT" } } } ] }

Ejemplo: garantizar que solo se permitan AWS CloudTrail eventos para API llamadas de una PrincipalId persona determinada

Todos los AWS CloudTrail eventos tienen la identidad PrincipalId del usuario que realizó la API llamada en la detail.userIdentity.principalId ruta de un evento. Con la clave de events:detail.userIdentity.principalId condición, puede limitar el acceso de IAM los usuarios o roles a los CloudTrail eventos solo a aquellos que provengan de una cuenta específica.

"Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutRuleOnlyForCloudTrailEventsWhereUserIsASpecificIAMUser", "Effect": "Allow", "Action": "events:PutRule", "Resource": "*", "Condition": { "StringEquals": { "events:detail-type": [ "AWS API Call via CloudTrail" ], "events:detail.userIdentity.principalId": [ "AIDAJ45Q7YFFAREXAMPLE" ] } } } ] }

En la tabla siguiente se ofrecen ejemplos de patrones de eventos que esta política permite o deniega.

Patrón de eventos Permitidos por la política
{ "detail-type": [ "AWS API Call via CloudTrail" ] }

No

{ "detail-type": [ "AWS API Call via CloudTrail" ], "detail.userIdentity.principalId": [ "AIDAJ45Q7YFFAREXAMPLE" ] }

{ "detail-type": [ "AWS API Call via CloudTrail" ], "detail.userIdentity.principalId": [ "AROAIDPPEZS35WEXAMPLE:AssumedRoleSessionName" ] }

No

Ejemplo: Limitación del acceso a los destinos

Si un IAM usuario o un rol tienen events:PutTargets permiso, pueden añadir cualquier destino de la misma cuenta a las reglas a las que se les permite acceder. La siguiente política limita la adición de destinos a solo una regla específica: MyRule en la cuenta 123456789012.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutTargetsOnASpecificRule", "Effect": "Allow", "Action": "events:PutTargets", "Resource": "arn:aws:events:us-east-1:123456789012:rule/MyRule" } ] }

Para limitar los destinos que se pueden añadir a la regla, utilice la clave de condición events:TargetArn. Por ejemplo, puede limitar destinos solo a funciones de Lambda, como en el siguiente ejemplo.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutTargetsOnASpecificRuleAndOnlyLambdaFunctions", "Effect": "Allow", "Action": "events:PutTargets", "Resource": "arn:aws:events:us-east-1:123456789012:rule/MyRule", "Condition": { "ArnLike": { "events:TargetArn": "arn:aws:lambda:*:*:function:*" } } } ] }