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 de la política de IAM en Amazon EventBridge
A la hora de conceder permisos, se utiliza el lenguaje de las políticas de IAM para especificar las condiciones en la que se debe aplicar una política. 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 especifica 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íticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/policyvariables.html) en la *Guía del usuario de IAM*. Para obtener más información sobre cómo especificar condiciones en un lenguaje de políticas de IAM, consulte [Condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html#Condition) en la *Guía del usuario de IAM*.
De forma predeterminada, los usuarios y los roles de IAM no pueden acceder a los [eventos](eb-events.md) en su cuenta. Para acceder a los eventos, un usuario debe estar autorizado para la acción del API `PutRule`. Si un usuario o un rol de IAM recibe autorización para la acción `events:PutRule`, puede crear una [regla](eb-rules.md) 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](eb-targets.md) a la regla.
Puede proporcionar una condición en la instrucción de política de un usuario o rol de IAM que permita a este crear una regla que solo coincida con un conjunto específico de orígenes y tipos de detalles. 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 proporcionar una condición en la instrucción de política de un usuario o rol de IAM que permita a este 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`.
## 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, Null |
| events:creatorAccount | `"events:creatorAccount":"creatorAccount"` Para*creatorAccount*, usa el ID de cuenta de la cuenta que creó la regla. Use esta condición para autorizar las llamadas a la API en reglas de una cuenta específica. | creatorAccount, Null |
| events:detail-type | `"events:detail-type":"detail-type "` Dónde *detail-type* está 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"` Para*eventTypeCode*, utilice la cadena literal para el **detalle. eventTypeCode**campo del evento, como`"AWS_ABUSE_DOS_REPORT"`. | eventTypeCode, Nulo |
| events: detail.service | `"events:detail.service":"service"` Para*service*, utilice la cadena literal para el campo **detail.service** del evento, como. `"ABUSE"` | servicio, Null |
| events: detail.userIdentity.principalId | `"events:detail.userIdentity.principalId":"principal-id"` Para*principal-id*, utilice la cadena literal del campo **detail.userIdentity.principalID** del evento con un tipo de detalle como. `"AWS API Call via CloudTrail"` `"AROAIDPPEZS35WEXAMPLE:AssumedRoleSessionName."` | ID de entidad principal, Null |
| eventos: eventBusInvocation | `"events:eventBusInvocation":"boolean"` Para*boolean*, utilice true cuando una regla envíe un evento a un objetivo que sea un bus de eventos de otra cuenta. Usa false cuando se utilice una llamada a la API `PutEvents`. | 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 "` *source*Utilícelo como cadena literal del campo de origen del evento, como `"aws.ec2"` o`"aws.s3"`. Para ver más valores posibles de*source*, consulte los eventos de ejemplo en[Eventos de los AWS servicios](eb-events.md#eb-service-event). | Origen, Null |
| eventos: TargetArn | `"events:TargetArn":"target-arn "` Para*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, consulte[Administrar los permisos de acceso a tus EventBridge recursos de Amazon](eb-manage-iam-access.md).
**Topics**
+ [EventBridge claves de condición](#conditions-table)
+ [EventBridge Características específicas de las tuberías](#eb-pipes-condition-diff)
+ [Ejemplo: Uso de la condición `creatorAccount`](#eb-events-creator-account)
+ [Ejemplo: Uso de la condición `eventBusInvocation`](#eb-events-bus-invocation)
+ [Ejemplo: Limitación del acceso a un origen específico](#eb-events-limit-access-control)
+ [Ejemplo: Definición de varios orígenes que puedan utilizarse en un patrón de eventos individualmente](#eb-events-pattern-sources)
+ [Ejemplo: Comprobación de que el origen se ha definido en el patrón de eventos](#eb-source-defined-events-pattern)
+ [Ejemplo: Definición de una lista de orígenes permitidos en un patrón de eventos con varios orígenes](#eb-allowed-sources-events-pattern)
+ [Ejemplo: Limitación del acceso a `PutRule` mediante `detail.service`](#eb-limit-rule-by-service)
+ [Ejemplo: Limitación del acceso a `PutRule` mediante `detail.eventTypeCode`](#eb-limit-rule-by-type-code)
+ [Ejemplo: garantizar que solo se permitan AWS CloudTrail los eventos relacionados con las llamadas a la API de una `PrincipalId` persona determinada](#eb-consume-specific-events)
+ [Ejemplo: Limitación del acceso a los destinos](#eb-limiting-access-to-targets)
## EventBridge Características específicas de las tuberías
EventBridge Pipes no admite ninguna clave de condición adicional de la política de IAM.
## 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.
------
#### [ JSON ]
****
```
{
"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`
La `eventBusInvocation` indica si la invocación se origina en un destino entre cuentas o en una solicitud de API `PutEvents`. 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 **false** cuando la invocación es el resultado de una solicitud de API `PutEvents`. El siguiente ejemplo indica una invocación desde un destino entre cuentas.
------
#### [ JSON ]
****
```
{
"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
Las siguientes políticas de ejemplo se pueden adjuntar a un usuario de IAM;. La Política A permite la acción de la API `PutRule` para todos los eventos, mientras que la Política B permite `PutRule` únicamente si el patrón de eventos de la regla que se crea coincide con eventos de Amazon EC2.
**Política A: permitir todos los eventos**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleForAllEvents",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*"
}
]
}
```
------
**Política B: permitir eventos solo desde Amazon EC2**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleForAllEC2Events",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"ForAllValues: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, al usuario con la Política B solo se le permite crear una regla que coincida con los eventos procedentes de Amazon EC2, por lo tanto, solo se le permite el acceso a los eventos desde Amazon EC2.
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" ]
} | Sí | Sí |
| {
"source": [ "aws.ec2", "aws.s3" ]
} | Sí | No (el origen aws.s3 no está permitido) |
| {
"source": [ "aws.ec2" ],
"detail-type": [ "EC2 Instance State-change Notification" ]
} | Sí | Sí |
| {
"detail-type": [ "EC2 Instance State-change Notification" ]
} | Sí | No (el origen debe especificarse) |
## Ejemplo: Definición de varios orígenes que puedan utilizarse en un patrón de eventos individualmente
El siguiente ejemplo permite a un usuario o rol de IAM crear una regla cuyo origen en el `EventPattern` sea Amazon EC2 o Amazon ECS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleIfSourceIsEC2OrECS",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"ForAllValues: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 del evento | Permitidos por la política |
| --- | --- |
| {
"source": [ "aws.ec2" ]
} | Sí |
| {
"source": [ "aws.ecs" ]
} | Sí |
| {
"source": [ "aws.s3" ]
} | No |
| {
"source": [ "aws.ec2", "aws.ecs" ]
} | No |
| {
"detail-type": [ "AWS API Call via CloudTrail" ]
} | 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 usuario o un rol de IAM no puede crear una regla con un `EventPattern` que no proporcione un origen específico.
------
#### [ JSON ]
****
```
{
"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" ]
} | Sí |
| {
"source": [ "aws.ecs", "aws.ec2" ]
} | Sí |
| {
"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.
------
#### [ JSON ]
****
```
{
"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" ]
} | Sí |
| {
"source": [ "aws.ec2", "aws.s3" ]
} | Sí |
| {
"source": [ "aws.ec2", "aws.autoscaling" ]
} | No |
| {
"detail-type": [ "EC2 Instance State-change Notification" ]
} | No |
## Ejemplo: Limitación del acceso a `PutRule` mediante `detail.service`
Puede restringir un usuario o un rol de IAM de forma que solo pueda crear reglas para eventos que tengan un determinado valor en el campo `events:details.service`. 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`.
------
#### [ JSON ]
****
```
{
"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 un usuario o un rol de IAM de forma que solo pueda crear reglas para eventos que tengan un determinado valor en el campo `events:details.eventTypeCode`. 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.eventTypeCode` sea `AWS_ABUSE_DOS_REPORT`.
------
#### [ JSON ]
****
```
{
"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 los eventos relacionados con las llamadas a la API de una `PrincipalId` persona determinada
Todos los AWS CloudTrail eventos tienen la PrincipalId identidad del usuario que realizó la llamada a la API en la `detail.userIdentity.principalId` ruta de un evento. Con la clave de `events:detail.userIdentity.principalId` condición, puede limitar el acceso de los usuarios o roles de IAM a los CloudTrail eventos únicamente 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 del evento | Permitidos por la política |
| --- | --- |
| {
"detail-type": [ "AWS API Call via CloudTrail" ]
} | No |
| {
"detail-type": [ "AWS API Call via CloudTrail" ],
"detail.userIdentity.principalId": [ "AIDAJ45Q7YFFAREXAMPLE" ]
} | Sí |
| {
"detail-type": [ "AWS API Call via CloudTrail" ],
"detail.userIdentity.principalId": [ "AROAIDPPEZS35WEXAMPLE:AssumedRoleSessionName" ]
} | No |
## Ejemplo: Limitación del acceso a los destinos
Si un usuario o un rol de IAM; tiene permiso `events:PutTargets`, puede añadir cualquier destino en la misma cuenta a las reglas a las que se les permita el acceso. La siguiente política limita la adición de destinos a solo una regla específica: `MyRule` en la cuenta `123456789012`.
------
#### [ JSON ]
****
```
{
"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.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutTargetsOnASpecificRuleAndOnlyLambdaFunctions",
"Effect": "Allow",
"Action": "events:PutTargets",
"Resource": "arn:aws:events:us-east-1:123456789012:rule/rule-name",
"Condition": {
"ForAnyValue:ArnLike": {
"events:TargetArn": "arn:aws:lambda:*:*:function:*"
}
}
}
]
}
```
------