Alex, MM2 is very conservative wrt replicating ACLs. Usually only MM2 is supposed to write to remote topics, so it usually doesn't make sense to replicate WRITE for other identities. Currently we only sync READ to remote topics, and we don't touch non-remote topics.
If your use-case requires replicating WRITE permission, you'll need to do it manually. Ryanne On Fri, Apr 15, 2022, 2:40 PM Alex Zuroff <azur...@gmail.com> wrote: > Hi, > > We are using MirrorMaker 2 (version 2.6.2 - to match our cluster version) > to migrate applications from one cluster to another, and as such, need the > topic ACLs to be the same on both clusters. The ACLs are being replicated, > but the operation is being set to "READ", even if the operation in the > source cluster was "ALL" or "WRITE". > > Here's an example ACL: > > Old cluster - > Current ACLs for resource `ResourcePattern(resourceType=TOPIC, > name=gms-price-logic-detail, patternType=LITERAL)`: > (principal=User:CN=MirrorMaker_DEV, host=*, operation=ALL, > permissionType=ALLOW) > (principal=User:CN=WGS_DEV, host=*, operation=ALL, permissionType=ALLOW) > > New cluster - > Current ACLs for resource `ResourcePattern(resourceType=TOPIC, > name=gms-price-logic-detail, patternType=LITERAL)`: > (principal=User:CN=WGS_DEV, host=*, operation=READ, permissionType=ALLOW) > (principal=User:CN=MirrorMaker_DEV, host=*, operation=READ, > permissionType=ALLOW) > > If I manually add an ALL ACL to a topic on the new cluster, MM2 will > sooner or later add another READ ACL to that same topic, even though the > ACLs now match. > > Is there some hidden config value I'm missing? I've verified in the logs > that "sync.topic.acls.enabled" is set to true. > > Thanks, > Alex > ** >
