Linkerd Authorization not working in multicluster communication context

[sockyone]

Hi Team. I'm trying to apply policy to linkerd multicluster using ServerAuthorization.
I don't know if there is a bug or not. I set my identity postfix to ".linkerd.cluster1.cluster.local" and "linkerd.cluster2.cluster.local"
Then I set ServerAuthorization in cluster 1 allows "*.linkerd.cluster1.cluster.local" and "more-detail.linkerd.cluster2.cluster.local". I want to allow all in the local cluster and some services in cluster 2. But when this applies to my service, everything in cluster 2 is able to call my service in cluster1. I have even tried removing "more-detail.linkerd.cluster2.cluster.local" from the policy but it's not working, every service in cluster 2 is still able to reach my service in cluster1.
If I set my rule specifically like serviceabc.linkerd.cluster1.cluster.local, it will work as my expectation.
How can I apply multicluster policy? Is it supported by Linkerd? Please help me (edited)

[mateiidavid]

Hey @sockyone,

I think I might've replied on Slack :) I'll reply here too in case it helps other people with similar issues. I'm going to use your examples of cluster 1 and cluster 2, where cluster 1 has exported services in cluster 2

A few words on how authz is enforced in multicluster scenarios: typically authz should be enforced at the gateway, and then once more for your service in cluster 2, from the gateway. For example, packets would have 3 hops: cluster 2: client --> cluster 1: gateway --> cluster 1: server.

All traffic from other clusters will have the identity of the gateway. This is sort of by design. Identity in Linkerd is tied to the workload. This means only pods can (and should) have identity. A group of pods share identity by using the same ServiceAccount. When we do service discovery on a target, we build identity for the endpoints: based on this identity, we'll know whether we can do TLS. If the identity is not present, for example, we'll get something like identity not provided by service discovery or no tls from remote. Gateways don't have any pods in cluster 2. Only a service. So when we create this service with an external destination, we tell it what identity it is supposed to have. So when requests come through, we can attempt to do mTLS. Once the gateway receives your request, it routes it to its actual target in cluster 1, hence why you don't see the initial identity.

Fine-grained authz in multicluster scenarios: any service in cluster 2 will be allowed to talk to any service in cluster 1, as long as the gateway allows the service to talk to it. However, we can limit who can talk to the service in cluster 1 by creating more gateways! The trick here is to enforce authorization at the gateway level, and not at the server/pod level. Imagine you wanted service A in cluster 1 to be reached only by client foo and service B in cluster 1 to be reached only by client bar. You create two gateways: first one allows only identity of foo, second allows only identity of bar.