Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Création de politiques d'autorisation pour le rôle IAM Attachez une politique d'autorisation au rôle IAM qui correspond au client. Dans une politique d'autorisation, vous spécifiez les actions à autoriser ou à refuser pour le rôle. Si votre client utilise une instance Amazon EC2, associez la politique d'autorisation au rôle IAM pour cette instance Amazon EC2. Vous pouvez également configurer votre client pour qu'il utilise un profil nommé, puis associer la politique d'autorisation au rôle de ce profil nommé. [Configurer les clients pour le contrôle d'accès IAM](configure-clients-for-iam-access-control.md) décrit comment configurer un client pour utiliser un profil nommé. Pour plus d'informations sur la création d'une politique IAM, consultez [Création de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html). Voici un exemple de politique d'autorisation pour un cluster nommé MyTestCluster. Pour comprendre la sémantique des éléments `Action` et `Resource`, consultez [Sémantique des politiques d'autorisation, des actions et des ressources de l'IAM](kafka-actions.md). **Important** Les modifications que vous apportez à une politique IAM sont reflétées dans l'IAM APIs et immédiatement. AWS CLI Cependant, la modification de la politique peut prendre un certain temps avant d'être effective. Dans la plupart des cas, les modifications de politique prennent effet en moins d'une minute. Les conditions du réseau peuvent parfois augmenter le délai. ------ #### [ 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/*" ] } ] } ``` ------ Pour savoir comment créer une politique avec des éléments d'action correspondant aux cas d'utilisation courants d'Apache Kafka, tels que la production et la consommation de données, consultez [Cas d'utilisation courants de la politique d'autorisation des clients](iam-access-control-use-cases.md). [Pour les versions 2.8.0 et supérieures de Kafka, l'**WriteDataIdempotently**autorisation est obsolète (KIP-679).](https://cwiki.apache.org/confluence/display/KAFKA/KIP-679%3A+Producer+will+enable+the+strongest+delivery+guarantee+by+default) Par défaut, `enable.idempotence = true` est défini. Par conséquent, pour les versions 2.8.0 et supérieures de Kafka, IAM n'offre pas les mêmes fonctionnalités que Kafka. ACLs Il n'est pas possible d'accéder `WriteDataIdempotently` à un sujet en fournissant uniquement `WriteData` l'accès à ce sujet. Cela n'affecte pas le cas lorsqu'il `WriteData` est fourni à **TOUS les** sujets. Dans ce cas, `WriteDataIdempotently` est autorisé. Cela est dû à des différences dans la mise en œuvre de la logique IAM et dans la manière dont les Kafka ACLs sont implémentés. De plus, écrire sur un sujet de manière idiote nécessite également un accès à. `transactional-ids` Pour contourner ce problème, nous vous recommandons d'utiliser une politique similaire à la suivante. ------ #### [ 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/*" ] } ] } ``` ------ Dans ce cas, `WriteData` autorise les écritures vers la `TestTopic`, pendant que `WriteDataIdempotently` autorise les écritures idempotentes sur le cluster. Cette politique ajoute également l'accès aux `transactional-id` ressources qui seront nécessaires. Comme il `WriteDataIdempotently` s'agit d'une autorisation au niveau du cluster, vous ne pouvez pas l'utiliser au niveau du sujet. Si elle `WriteDataIdempotently` est limitée au niveau du sujet, cette politique ne fonctionnera pas.