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.

# Creación de políticas de autorización para el rol de IAM
<a name="create-iam-access-control-policies"></a>

Asocie una política de autorización al rol de IAM que corresponda al cliente. En una política de autorización, se especifican las acciones que se van a permitir o denegar para el rol. Si su cliente está en una instancia de Amazon EC2, asocie la política de autorización al rol de IAM de esa instancia de Amazon EC2. Como alternativa, puede configurar su cliente para que utilice un perfil con nombre y, a continuación, asociar la política de autorización al rol de ese perfil con nombre. [Configuración de clientes para el control de acceso de IAM](configure-clients-for-iam-access-control.md) describe cómo configurar un cliente para utilizar un perfil con nombre asignado.

Para obtener más información sobre cómo crear una política de IAM, consulte [Creación de políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html). 

A continuación, se muestra un ejemplo de política de autorización para un clúster denominado MyTestCluster. Para entender la semántica de los elementos `Action` y `Resource`, consulte [Semántica de las acciones y los recursos de la política de autorización de IAM](kafka-actions.md).

**importante**  
Los cambios que realices en una política de IAM se reflejan en el IAM APIs e inmediatamente. AWS CLI Sin embargo, puede pasar un tiempo considerable hasta que el cambio en la política surta efecto. En la mayoría de los casos, los cambios en la política entran en vigor en menos de un minuto. En ocasiones, las condiciones de la red pueden aumentar la demora.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kafka-cluster:Connect",
                "kafka-cluster:AlterCluster",
                "kafka-cluster:DescribeCluster"
            ],
            "Resource": [
                "arn:aws:kafka:us-east-1:{{111122223333}}:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kafka-cluster:*Topic*",
                "kafka-cluster:WriteData",
                "kafka-cluster:ReadData"
            ],
            "Resource": [
                "arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kafka-cluster:AlterGroup",
                "kafka-cluster:DescribeGroup"
            ],
            "Resource": [
                "arn:aws:kafka:us-east-1:123456789012:group/MyTestCluster/*"
            ]
        }
    ]
}
```

------

Para obtener información sobre cómo crear una política con elementos de acción que se correspondan con los casos de uso habituales de Apache Kafka, como la producción y el consumo de datos, consulte [Casos de uso habituales de la política de autorización de clientes](iam-access-control-use-cases.md).

[En las versiones 2.8.0 y posteriores de Kafka, el **WriteDataIdempotently**permiso está obsoleto (KIP-679).](https://cwiki.apache.org/confluence/display/KAFKA/KIP-679%3A+Producer+will+enable+the+strongest+delivery+guarantee+by+default) Se utiliza `enable.idempotence = true` de forma predeterminada. Por lo tanto, para las versiones 2.8.0 y posteriores de Kafka, IAM no ofrece la misma funcionalidad que Kafka. ACLs No es posible `WriteDataIdempotently` en un tema si se proporciona únicamente acceso de `WriteData` a ese tema. Esto no afecta al caso en el que se proporciona `WriteData` a **TODOS** los temas. En ese caso, `WriteDataIdempotently` está permitido. Esto se debe a las diferencias en la implementación de la lógica de IAM y en la forma en que se implementa la Kafka. ACLs Además, la escritura idempotente en un tema también requiere acceso a `transactional-ids`.

Para solucionar esta limitación, se recomienda utilizar una política similar a la que se muestra a continuación.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kafka-cluster:Connect",
                "kafka-cluster:AlterCluster",
                "kafka-cluster:DescribeCluster",
                "kafka-cluster:WriteDataIdempotently"
            ],
            "Resource": [
                "arn:aws:kafka:us-east-1:123456789012:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kafka-cluster:*Topic*",
                "kafka-cluster:WriteData",
                "kafka-cluster:ReadData"
            ],
            "Resource": [
                "arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/TestTopic",
                "arn:aws:kafka:us-east-1:123456789012:transactional-id/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*"
            ]
        }
    ]
}
```

------

En este caso, `WriteData` permite escribir en `TestTopic` y, al mismo tiempo, `WriteDataIdempotently` permite escrituras idempotentes en el clúster. Esta política también agrega acceso a los recursos de `transactional-id` que serán necesarios.

Dado que `WriteDataIdempotently` es un permiso de clúster, no se puede utilizar en los temas. Si `WriteDataIdempotently` se restringe al nivel de tema, esta política no funcionará.