Egress Rules


Egress rules describe the properties of a service outside Istio. When transparent proxying is used, egress rules signify a white listed set of domains that microservices in the mesh are allowed to access. A subset of routing rules and all destination policies can be applied on the service targeted by an egress rule. The destination of an egress rule is allowed to contain wildcards (e.g., * Currently, only HTTP-based services can be expressed through the egress rule. If TLS origination from the sidecar is desired, the protocol associated with the service port must be marked as HTTPS, and the service is expected to be accessed over HTTP (e.g., The sidecar will automatically upgrade the connection to TLS when initiating a connection with the external service.

For example, the following egress rule describes the set of services hosted under the * domain

kind: EgressRule
  name: foo-egress-rule
    service: *
    - port: 80
      protocol: http
    - port: 443
      protocol: https
Field Type Description
destination IstioService REQUIRED: Hostname or a wildcard domain name associated with the external service. ONLY the "service" field of destination will be taken into consideration. Name, namespace, domain and labels are ignored. Routing rules and destination policies that refer to these external services must have identical specification for the destination as the corresponding egress rule. Wildcard domain specifications must conform to format allowed by Envoy's Virtual Host specification, such as “*” or “*”. The character '*' in a domain specification indicates a non-empty string. Hence, a wildcard domain of form “*” will match “” but not “”.
ports[] repeated Port REQUIRED: list of ports on which the external service is available.


Port describes the properties of a specific TCP port of an external service.

Field Type Description
port int32 A valid non-negative integer port number.
protocol string The protocol to communicate with the external services. MUST BE one of HTTP|HTTPS|GRPC|HTTP2.