As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Criar políticas de autorização para o perfil do IAM
<a name="create-iam-access-control-policies"></a>

Anexe uma política de autorização ao perfil do IAM correspondente ao cliente. Em uma política de autorização, você especifica quais ações permitir ou proibir para o perfil. Se seu cliente estiver em uma instância do Amazon EC2, associe a política de autorização ao perfil do IAM para essa instância do Amazon EC2. Como alternativa, você pode configurar seu cliente para usar um perfil nomeado e, em seguida, associar a política de autorização ao perfil desse perfil nomeado. [Configurar clientes para controle de acesso do IAM](configure-clients-for-iam-access-control.md) descreve como configurar um cliente para usar um perfil nomeado.

Para obter informações sobre como criar uma política do IAM, consulte [Criar políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html). 

Veja a seguir um exemplo de política de autorização para um cluster chamado MyTestCluster. Para entender a semântica dos elementos `Action` e `Resource`, consulte [Semântica das ações e recursos da política de autorização do IAM](kafka-actions.md).

**Importante**  
As alterações que você faz em uma política do IAM são refletidas no IAM APIs e AWS CLI imediatamente. No entanto, a implementação da alteração da política pode levar um tempo considerável. Na maioria dos casos, as mudanças na política entram em vigor em menos de um minuto. Às vezes, as condições da rede podem aumentar o atraso.

------
#### [ 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 saber como criar uma política com elementos de ação que correspondam aos casos de uso comuns do Apache Kafka, como produzir e consumir dados, consulte [Casos de uso comuns para a política de autorização de clientes](iam-access-control-use-cases.md).

[Para as versões 2.8.0 e superiores do Kafka, a **WriteDataIdempotently**permissão está obsoleta (KIP-679).](https://cwiki.apache.org/confluence/display/KAFKA/KIP-679%3A+Producer+will+enable+the+strongest+delivery+guarantee+by+default) `enable.idempotence = true` é usado por padrão. Portanto, para as versões 2.8.0 e superiores do Kafka, o IAM não oferece a mesma funcionalidade do Kafka. ACLs Não é possível atribuir `WriteDataIdempotently` a um tópico fornecendo apenas acesso `WriteData` a esse tópico. Isso não afeta o caso quando `WriteData` é fornecido para **TODOS** os tópicos. Nesse caso, `WriteDataIdempotently` é permitido. Isso se deve às diferenças na implementação da lógica do IAM e na forma como os Kafka ACLs são implementados. E escrever em um tópico de forma idempotente também requer acesso a `transactional-ids`.

Para contornar a questão, recomendamos o uso de uma política semelhante à política abaixo.

------
#### [ 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/*"
            ]
        }
    ]
}
```

------

Nesse caso, `WriteData` permite gravações em `TestTopic`, enquanto `WriteDataIdempotently` permite gravações idempotentes no cluster. Essa política também adiciona acesso aos recursos `transactional-id` que serão necessários.

Como `WriteDataIdempotently` é uma permissão no nível do cluster, você não pode usá-la no nível do tópico. Se `WriteDataIdempotently` estiver restrita ao nível do tópico, essa política não funcionará.