AWS msk medium security documentation change
Summary
Updated policy examples with valid account ID, clarified idempotent write requirements, and added transactional-id resource to policy example
Security assessment
Addresses a security gap by documenting required transactional-id access for idempotent writes, which could prevent misconfigured policies from allowing unintended access
Diff
diff --git a/msk/latest/developerguide/create-iam-access-control-policies.md b/msk/latest/developerguide/create-iam-access-control-policies.md index 62a62c12e..33f0de662 100644 --- a//msk/latest/developerguide/create-iam-access-control-policies.md +++ b//msk/latest/developerguide/create-iam-access-control-policies.md @@ -40 +40 @@ Changes that you make to an IAM policy are reflected in the IAM APIs and the AWS - "arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/*" + "arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/*" @@ -50 +50 @@ Changes that you make to an IAM policy are reflected in the IAM APIs and the AWS - "arn:aws:kafka:us-east-1:0123456789012:group/MyTestCluster/*" + "arn:aws:kafka:us-east-1:123456789012:group/MyTestCluster/*" @@ -58 +58 @@ To learn how to create a policy with action elements that correspond to common A -For Kafka versions 2.8.0 and above, the **WriteDataIdempotently** permission is deprecated ([KIP-679](https://cwiki.apache.org/confluence/display/KAFKA/KIP-679%3A+Producer+will+enable+the+strongest+delivery+guarantee+by+default)). By default,`enable.idempotence = true` is set. Therefore, for Kafka versions 2.8.0 and above, IAM does not offer the same functionality as Kafka ACLs. It is not possible to `WriteDataIdempotently` to a topic by only providing `WriteData` access to that topic. This does not affect the case when `WriteData` is provided to **ALL** topics. In that case, `WriteDataIdempotently` is allowed. This is due to differences in implementation of IAM logic versus how the Kafka ACLs are implemented. +For Kafka versions 2.8.0 and above, the **WriteDataIdempotently** permission is deprecated ([KIP-679](https://cwiki.apache.org/confluence/display/KAFKA/KIP-679%3A+Producer+will+enable+the+strongest+delivery+guarantee+by+default)). By default,`enable.idempotence = true` is set. Therefore, for Kafka versions 2.8.0 and above, IAM doesn't offer the same functionality as Kafka ACLs. It isn't possible to `WriteDataIdempotently` to a topic by only providing `WriteData` access to that topic. This doesn't affect the case when `WriteData` is provided to **ALL** topics. In that case, `WriteDataIdempotently` is allowed. This is due to differences in implementation of IAM logic and how the Kafka ACLs are implemented. Additonally, writing to a topic idempotently also requires access to `transactional-ids`. @@ -60 +60 @@ For Kafka versions 2.8.0 and above, the **WriteDataIdempotently** permission is -To work around this, we recommend using a policy similar to the sample below: +To work around this, we recommend using a policy similar to the following policy. @@ -75 +75 @@ To work around this, we recommend using a policy similar to the sample below: - "arn:aws:kafka:us-east-1:0123456789012:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1" + "arn:aws:kafka:us-east-1:123456789012:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1" @@ -86 +86,2 @@ To work around this, we recommend using a policy similar to the sample below: - "arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/TestTopic" + "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/*" @@ -92 +93,3 @@ To work around this, we recommend using a policy similar to the sample below: -In this case, `WriteData` allows writes to `TestTopic`, while `WriteDataIdempotently` allows idempotent writes to the cluster. It is important to note that `WriteDataIdempotently` is a cluster level permission. It cannot be used at the topic level. If `WriteDataIdempotently` is restricted to the topic level, this policy will not work. +In this case, `WriteData` allows writes to `TestTopic`, while `WriteDataIdempotently` allows idempotent writes to the cluster. This policy also adds access to the `transactional-id` resources that will be needed. + +Because `WriteDataIdempotently` is a cluster level permission, you can't use it at the topic level. If `WriteDataIdempotently` is restricted to the topic level, this policy won't work.