istio: Wildcard destination rules are silently ignored when Spec.Host specifies a different namespace from its definition

Bug description Wildcard destination rules defined in a namespace for services in a different namespace with exportTo=* are not globally exported, but are silently ignored. This does not pertain to istio-system namespace.

Affected product area (please put an X in all that apply)

[ ] Configuration Infrastructure [X] Docs [ ] Installation [ ] Networking [ ] Performance and Scalability [X] Policies and Telemetry [ ] Security [ ] Test and Release [X] User Experience

Expected behavior Globally exported destination rules that match a host based on wildcards would have their configuration propagated to envoy sidecars based on the most specific wildcard matching (e.g. *.namespace.svc.cluster.local has precedence over *.local).

Steps to reproduce the bug

1. Install bookinfo in the default namespace
2. Create a new namespace, ‘foo’
3. Apply the following destination rule:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: foo-destinationrule
  namespace: foo
spec:
  exportTo:
  - '*'
  host: "*.default.svc.cluster.local"
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
        connectTimeout: 30ms
    loadBalancer:
      simple: LEAST_CONN

1. Using istioctl examine the proxy config of a pod in the default namespace; in this case productpage (e.g. istioctl proxy-config clusters productpage-v1-6597cb5df9-bnxlz -o json).

Here is a snippet of the config when using istio-auth.yaml at the top level (istio-system has a rule for using mTLS globally for *.local).

The left side shows when the same destination rule is applied in the same namespace whereas the right shows when it is defined in a different namespace.

1. Change the above destination rule to be in namespace ‘default’ and re-apply.
2. When inspecting the proxy config of a pod in the namespace the above destination rule is propagated to the envoy sidecar.

Version (include the output of istioctl version --remote and kubectl version) 1.1.3

How was Istio installed? Install with Helm via helm template.

Environment where bug was observed (cloud vendor, OS, etc) Kops installed kubernetes cluster on AWS; kubernetes 1.12.7 server.