In a multi-primary deployment, you want to ensure that traffic between clusters is encrypted via mTLS. Which resource must be configured on both clusters?
Trap 1: A ServiceEntry with 'resolution: DNS'.
ServiceEntry registers external hosts into the mesh registry so sidecars can route to them; it carries no certificate or trust configuration. It is the correct resource when you need to reach services outside the mesh, not for securing east-west traffic between two primary clusters.
Trap 2: An AuthorizationPolicy allowing all traffic.
AuthorizationPolicy governs whether requests are permitted or denied at the sidecar; it does not provision the certificates or trust bundles that establish mTLS between clusters. It would be the right resource for enforcing access rules on workloads once mutual TLS is already configured.
Trap 3: An EgressGateway with TLS origination.
An EgressGateway with TLS origination terminates and re-originates TLS for traffic leaving the mesh toward external destinations. Multi-primary cluster-to-cluster mTLS relies on shared trust roots and remote secrets, not on an egress gateway terminating connections.
- A
A shared 'cacerts' secret containing the root CA certificate.
A shared 'cacerts' secret supplies the root CA certificate each cluster's Istio control plane uses to verify peer certificates during the mTLS handshake. Because both clusters trust the same root, cross-cluster certificate validation succeeds, satisfying the stem's requirement that inter-cluster traffic be mutually authenticated and encrypted.
- B
A ServiceEntry with 'resolution: DNS'.
Why it fails: ServiceEntry registers external hosts into the mesh registry so sidecars can route to them; it carries no certificate or trust configuration. It is the correct resource when you need to reach services outside the mesh, not for securing east-west traffic between two primary clusters.
- C
An AuthorizationPolicy allowing all traffic.
Why it fails: AuthorizationPolicy governs whether requests are permitted or denied at the sidecar; it does not provision the certificates or trust bundles that establish mTLS between clusters. It would be the right resource for enforcing access rules on workloads once mutual TLS is already configured.
- D
An EgressGateway with TLS origination.
Why it fails: An EgressGateway with TLS origination terminates and re-originates TLS for traffic leaving the mesh toward external destinations. Multi-primary cluster-to-cluster mTLS relies on shared trust roots and remote secrets, not on an egress gateway terminating connections.