翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # IAM ロールの認可ポリシーを作成する クライアントに対応する IAM ロールに認可ポリシーを添付します。認可ポリシーでは、ロールに対して許可または拒否するアクションを指定します。クライアントが Amazon EC2 インスタンス上にある場合は、認可ポリシーをその Amazon EC2 インスタンスの IAM ロールに関連付けます。または、名前付きプロファイルを使用するようにクライアントを設定してから、認可ポリシーをその名前付きプロファイルのロールに関連付けることができます。 [IAM アクセス制御用にクライアントを設定する](configure-clients-for-iam-access-control.md) は、名前付きプロファイルを使用するようにクライアントを設定する方法を説明しています。 IAM ポリシーを作成する方法については、[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)を参照してください。 以下は、MyTestCluster という名前のクラスターの認可ポリシーの例です。`Action` 要素と `Resource` 要素のセマンティクスを理解するには、「[IAM 認可ポリシーアクションとリソースのセマンティクス](kafka-actions.md)」を参照してください。 **重要** IAM ポリシーに加えた変更は、IAM API と AWS CLI にすぐに反映されます。ただし、ポリシーの変更が有効になるまでにかなりの時間がかかる場合があります。ほとんどの場合、ポリシーの変更は1分以内に有効になります。ネットワークの状態により、遅延が増える場合があります。 ------ #### [ 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/*" ] } ] } ``` ------ データの生成や消費など、一般的な Apache Kafka のユースケースに対応するアクション要素を使用してポリシーを作成する方法については、「[クライアント認可ポリシーの一般的なユースケース](iam-access-control-use-cases.md)」を参照してください。 Kafka バージョン 2.8.0 以降では、**WriteDataIdempotently** アクセス許可は廃止されました ([KIP-679](https://cwiki.apache.org/confluence/display/KAFKA/KIP-679%3A+Producer+will+enable+the+strongest+delivery+guarantee+by+default))。デフォルトでは、`enable.idempotence = true` が設定されています。したがって、Kafka バージョン 2.8.0 以降では、IAM は Kafka ACL と同じ機能を提供しません。そのトピックへの `WriteData` アクセス権限を提供するだけでは、トピックに対して `WriteDataIdempotently` を実行することはできません。これは、`WriteData` が**すべて**のトピックに提供されている場合には該当しません。その場合は、`WriteDataIdempotently` は許可されます。これは、 IAM ロジックの実装と Kafka ACL の実装方法の違いによるものです。さらに、トピックにべき等的に書き込むには、`transactional-ids` へのアクセスも必要です。 この問題を回避するために、以下のようなポリシーを使用することが推奨されます。 ------ #### [ 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/*" ] } ] } ``` ------ この場合、`WriteData` への書き込みを許可する`TestTopic`と同時に`WriteDataIdempotently`、 クラスターへの冪等性書き込みを許可します。このポリシーは、必要な `transactional-id` リソースへのアクセスも追加します。 なぜなら、`WriteDataIdempotently` は、クラスターレベルのアクセス許可であるため、トピックレベルでは使用できません。もし、`WriteDataIdempotently` がトピックレベルに制限されている場合、このポリシーは機能しません。