As I understand it, AuthorizationPolicy enforcement happens in the server side Envoy’s identified by a policy’s selector labels, but MESH_EXTERNAL ServiceEntries don’t have a server side Envoy because they are external to the mesh.
How do we enforce AuthroizationPolicy on ServiceEntries for resources outside the mesh?
I am not an Istio developer, however the way I have been thinking about it, AuthorizationPolicy is mainly for entities that have identity assigned by the Mesh, i.e things internal to the mesh.
If you are using an egress gateway to funnel all MESH_EXTERNAL traffic out of the mesh, you could apply AuthorizationPolicy against the routes between workload -> egress gateway, restricting access to the target hosts: as long as you deny all egress traffic directly from sidecars.
If you are doing direct egress from workload sidecars and don’t want the extra egress-gateway hop, you could take an approach like we do, which is to use the Sidecar API to control which workloads each ServiceEntry is visible to. This effectively requires defining your ServiceEntrys in a different namespace to the workloads using them and defining a default SideCar egress rule to give workloads visibility of only services in the same namespace (or istio-system). This is the suggested default Sidecar definition in the docs.
Adding onto Chad’s solution, If I’m understanding your problem correctly, I would say you would also want to have the global.outboundTrafficPolicy.mode setting set to REGISTRY_ONLY. This would make sure external communication is handled by the policies you’ve created and nothing is bypassed.