Service Entry

ServiceEntry enables adding additional entries into Istio’s internalservice registry, so that auto-discovered services in the mesh canaccess/route to these manually specified services. A service entrydescribes the properties of a service (DNS name, VIPs, ports, protocols,endpoints). These services could be external to the mesh (e.g., webAPIs) or mesh-internal services that are not part of the platform’sservice registry (e.g., a set of VMs talking to services in Kubernetes).

The following example declares a few external APIs accessed by internalapplications over HTTPS. The sidecar inspects the SNI value in theClientHello message to route to the appropriate external service.

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: ServiceEntry
  3. metadata:
  4. name: external-svc-https
  5. spec:
  6. hosts:
  7. - api.dropboxapi.com
  8. - www.googleapis.com
  9. - api.facebook.com
  10. location: MESH_EXTERNAL
  11. ports:
  12. - number: 443
  13. name: https
  14. protocol: TLS
  15. resolution: DNS

The following configuration adds a set of MongoDB instances running onunmanaged VMs to Istio’s registry, so that these services can be treatedas any other service in the mesh. The associated DestinationRule is usedto initiate mTLS connections to the database instances.

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: ServiceEntry
  3. metadata:
  4. name: external-svc-mongocluster
  5. spec:
  6. hosts:
  7. - mymongodb.somedomain # not used
  8. addresses:
  9. - 192.192.192.192/24 # VIPs
  10. ports:
  11. - number: 27018
  12. name: mongodb
  13. protocol: MONGO
  14. location: MESH_INTERNAL
  15. resolution: STATIC
  16. endpoints:
  17. - address: 2.2.2.2
  18. - address: 3.3.3.3

and the associated DestinationRule

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: DestinationRule
  3. metadata:
  4. name: mtls-mongocluster
  5. spec:
  6. host: mymongodb.somedomain
  7. trafficPolicy:
  8. tls:
  9. mode: MUTUAL
  10. clientCertificate: /etc/certs/myclientcert.pem
  11. privateKey: /etc/certs/client_private_key.pem
  12. caCertificates: /etc/certs/rootcacerts.pem

The following example uses a combination of service entry and TLSrouting in a virtual service to steer traffic based on the SNI value toan internal egress firewall.

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: ServiceEntry
  3. metadata:
  4. name: external-svc-redirect
  5. spec:
  6. hosts:
  7. - wikipedia.org
  8. - "*.wikipedia.org"
  9. location: MESH_EXTERNAL
  10. ports:
  11. - number: 443
  12. name: https
  13. protocol: TLS
  14. resolution: NONE

And the associated VirtualService to route based on the SNI value.

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: VirtualService
  3. metadata:
  4. name: tls-routing
  5. spec:
  6. hosts:
  7. - wikipedia.org
  8. - "*.wikipedia.org"
  9. tls:
  10. - match:
  11. - sniHosts:
  12. - wikipedia.org
  13. - "*.wikipedia.org"
  14. route:
  15. - destination:
  16. host: internal-egress-firewall.ns1.svc.cluster.local

The virtual service with TLS match serves to override the default SNImatch. In the absence of a virtual service, traffic will be forwarded tothe wikipedia domains.

The following example demonstrates the use of a dedicated egress gatewaythrough which all external service traffic is forwarded.The ‘exportTo’ field allows for control over the visibility of a servicedeclaration to other namespaces in the mesh. By default, a service is exportedto all namespaces. The following example restricts the visibility to thecurrent namespace, represented by “.”, so that it cannot be used by othernamespaces.

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: ServiceEntry
  3. metadata:
  4. name: external-svc-httpbin
  5. namespace : egress
  6. spec:
  7. hosts:
  8. - httpbin.com
  9. exportTo:
  10. - "."
  11. location: MESH_EXTERNAL
  12. ports:
  13. - number: 80
  14. name: http
  15. protocol: HTTP
  16. resolution: DNS

Define a gateway to handle all egress traffic.

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: Gateway
  3. metadata:
  4. name: istio-egressgateway
  5. namespace: istio-system
  6. spec:
  7. selector:
  8. istio: egressgateway
  9. servers:
  10. - port:
  11. number: 80
  12. name: http
  13. protocol: HTTP
  14. hosts:
  15. - "*"

And the associated VirtualService to route from the sidecar to thegateway service (istio-egressgateway.istio-system.svc.cluster.local), aswell as route from the gateway to the external service. Note that thevirtual service is exported to all namespaces enabling them to route trafficthrough the gateway to the external service. Forcing traffic to go througha managed middle proxy like this is a common practice.

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: VirtualService
  3. metadata:
  4. name: gateway-routing
  5. namespace: egress
  6. spec:
  7. hosts:
  8. - httpbin.com
  9. exportTo:
  10. - "*"
  11. gateways:
  12. - mesh
  13. - istio-egressgateway
  14. http:
  15. - match:
  16. - port: 80
  17. gateways:
  18. - mesh
  19. route:
  20. - destination:
  21. host: istio-egressgateway.istio-system.svc.cluster.local
  22. - match:
  23. - port: 80
  24. gateways:
  25. - istio-egressgateway
  26. route:
  27. - destination:
  28. host: httpbin.com

The following example demonstrates the use of wildcards in the hosts forexternal services. If the connection has to be routed to the IP addressrequested by the application (i.e. application resolves DNS and attemptsto connect to a specific IP), the discovery mode must be set to NONE.

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: ServiceEntry
  3. metadata:
  4. name: external-svc-wildcard-example
  5. spec:
  6. hosts:
  7. - "*.bar.com"
  8. location: MESH_EXTERNAL
  9. ports:
  10. - number: 80
  11. name: http
  12. protocol: HTTP
  13. resolution: NONE

The following example demonstrates a service that is available via aUnix Domain Socket on the host of the client. The resolution must beset to STATIC to use Unix address endpoints.

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: ServiceEntry
  3. metadata:
  4. name: unix-domain-socket-example
  5. spec:
  6. hosts:
  7. - "example.unix.local"
  8. location: MESH_EXTERNAL
  9. ports:
  10. - number: 80
  11. name: http
  12. protocol: HTTP
  13. resolution: STATIC
  14. endpoints:
  15. - address: unix:///var/run/example/socket

For HTTP-based services, it is possible to create a VirtualServicebacked by multiple DNS addressable endpoints. In such a scenario, theapplication can use the HTTP_PROXY environment variable to transparentlyreroute API calls for the VirtualService to a chosen backend. Forexample, the following configuration creates a non-existent externalservice called foo.bar.com backed by three domains: us.foo.bar.com:8080,uk.foo.bar.com:9080, and in.foo.bar.com:7080

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: ServiceEntry
  3. metadata:
  4. name: external-svc-dns
  5. spec:
  6. hosts:
  7. - foo.bar.com
  8. location: MESH_EXTERNAL
  9. ports:
  10. - number: 80
  11. name: http
  12. protocol: HTTP
  13. resolution: DNS
  14. endpoints:
  15. - address: us.foo.bar.com
  16. ports:
  17. https: 8080
  18. - address: uk.foo.bar.com
  19. ports:
  20. https: 9080
  21. - address: in.foo.bar.com
  22. ports:
  23. https: 7080

With HTTP_PROXY=http://localhost/, calls from the application tohttp://foo.bar.com will be load balanced across the three domainsspecified above. In other words, a call to http://foo.bar.com/baz wouldbe translated to http://uk.foo.bar.com/baz.

The following example illustrates the usage of a ServiceEntrycontaining a subject alternate namewhose format conforms to the SPIFFE standard:

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: ServiceEntry
  3. metadata:
  4. name: httpbin
  5. namespace : httpbin-ns
  6. spec:
  7. hosts:
  8. - httpbin.com
  9. location: MESH_INTERNAL
  10. ports:
  11. - number: 80
  12. name: http
  13. protocol: HTTP
  14. resolution: STATIC
  15. endpoints:
  16. - address: 2.2.2.2
  17. - address: 3.3.3.3
  18. subjectAltNames:
  19. - "spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account"

ServiceEntry

ServiceEntry enables adding additional entries into Istio’s internalservice registry.

FieldTypeDescriptionRequired
hostsstring[]
The hosts associated with the ServiceEntry. Could be a DNSname with wildcard prefix.

- The hosts field is used to select matching hosts in VirtualServices and DestinationRules.
- For HTTP traffic the HTTP Host/Authority header will be matched against the hosts field.
- For HTTPs or TLS traffic containing Server Name Indication (SNI), the SNI valuewill be matched against the hosts field.
Note that when resolution is set to type DNSand no endpoints are specified, the host field will be used as the DNS nameof the endpoint to route traffic to.
Yes
addressesstring[]
The virtual IP addresses associated with the service. Could be CIDRprefix. For HTTP traffic, generated route configurations will include http routedomains for both the addresses and hosts field values and the destination willbe identified based on the HTTP Host/Authority header.If one or more IP addresses are specified,the incoming traffic will be identified as belonging to this serviceif the destination IP matches the IP/CIDRs specified in the addressesfield. If the Addresses field is empty, traffic will be identifiedsolely based on the destination port. In such scenarios, the port onwhich the service is being accessed must not be shared by any otherservice in the mesh. In other words, the sidecar will behave as asimple TCP proxy, forwarding incoming traffic on a specified port tothe specified destination endpoint IP/host. Unix domain socketaddresses are not supported in this field.
No
portsPort[]
The ports associated with the external service. If theEndpoints are Unix domain socket addresses, there must be exactly oneport.
Yes
locationLocation
Specify whether the service should be considered external to the meshor part of the mesh.
No
resolutionResolution
Service discovery mode for the hosts. Care must be takenwhen setting the resolution mode to NONE for a TCP port withoutaccompanying IP addresses. In such cases, traffic to any IP onsaid port will be allowed (i.e. 0.0.0.0:).
Yes
endpointsEndpoint[]
One or more endpoints associated with the service.
No
exportTostring[]
A list of namespaces to which this service is exported. Exporting a serviceallows it to be used by sidecars, gateways and virtual services defined inother namespaces. This feature provides a mechanism for service ownersand mesh administrators to control the visibility of services acrossnamespace boundaries.

If no namespaces are specified then the service is exported to allnamespaces by default.

The value “.” is reserved and defines an export to the same namespace thatthe service is declared in. Similarly the value “” is reserved anddefines an export to all namespaces.

For a Kubernetes Service, the equivalent effect can be achieved by settingthe annotation “networking.istio.io/exportTo” to a comma-separated listof namespace names.

NOTE: in the current release, the exportTo value is restricted to“.” or “
” (i.e., the current namespace or all namespaces).
No
subjectAltNamesstring[]
The list of subject alternate names allowed for workload instances thatimplement this service. This information is used to enforcesecure-naming.If specified, the proxy will verify that the servercertificate’s subject alternate name matches one of the specified values.
No

ServiceEntry.Endpoint

Endpoint defines a network address (IP or hostname) associated withthe mesh service.

FieldTypeDescriptionRequired
addressstring
Address associated with the network endpoint without theport. Domain names can be used if and only if the resolution is setto DNS, and must be fully-qualified without wildcards. Use the formunix:///absolute/path/to/socket for Unix domain socket endpoints.
Yes
portsmap<string, uint32>
Set of ports associated with the endpoint. The ports must beassociated with a port name that was declared as part of theservice. Do not use for unix:// addresses.
No
labelsmap<string, string>
One or more labels associated with the endpoint.
No
networkstring
Network enables Istio to group endpoints resident in the same L3domain/network. All endpoints in the same network are assumed to bedirectly reachable from one another. When endpoints in differentnetworks cannot reach each other directly, an Istio Gateway can beused to establish connectivity (usually using theAUTO_PASSTHROUGH mode in a Gateway Server). This isan advanced configuration used typically for spanning an Istio meshover multiple clusters.
No
localitystring
The locality associated with the endpoint. A locality correspondsto a failure domain (e.g., country/region/zone). Arbitrary failuredomain hierarchies can be represented by separating eachencapsulating failure domain by /. For example, the locality of anan endpoint in US, in US-East-1 region, within availability zoneaz-1, in data center rack r11 can be represented asus/us-east-1/az-1/r11. Istio will configure the sidecar to route toendpoints within the same locality as the sidecar. If none of theendpoints in the locality are available, endpoints parent locality(but within the same network ID) will be chosen. For example, ifthere are two endpoints in same network (networkID “n1”), say e1with locality us/us-east-1/az-1/r11 and e2 with localityus/us-east-1/az-2/r12, a sidecar from us/us-east-1/az-1/r11 localitywill prefer e1 from the same locality over e2 from a differentlocality. Endpoint e2 could be the IP associated with a gateway(that bridges networks n1 and n2), or the IP associated with astandard service endpoint.
No
weightuint32
The load balancing weight associated with the endpoint. Endpointswith higher weights will receive proportionally higher traffic.
No

ServiceEntry.Location

Location specifies whether the service is part of Istio mesh oroutside the mesh. Location determines the behavior of severalfeatures, such as service-to-service mTLS authentication, policyenforcement, etc. When communicating with services outside the mesh,Istio’s mTLS authentication is disabled, and policy enforcement isperformed on the client-side as opposed to server-side.

NameDescription
MESH_EXTERNAL
Signifies that the service is external to the mesh. Typically usedto indicate external services consumed through APIs.
MESH_INTERNAL
Signifies that the service is part of the mesh. Typically used toindicate services added explicitly as part of expanding the servicemesh to include unmanaged infrastructure (e.g., VMs added to aKubernetes based service mesh).

ServiceEntry.Resolution

Resolution determines how the proxy will resolve the IP addresses ofthe network endpoints associated with the service, so that it canroute to one of them. The resolution mode specified here has no impacton how the application resolves the IP address associated with theservice. The application may still have to use DNS to resolve theservice to an IP so that the outbound traffic can be captured by theProxy. Alternatively, for HTTP services, the application coulddirectly communicate with the proxy (e.g., by setting HTTP_PROXY) totalk to these services.

NameDescription
NONE
Assume that incoming connections have already been resolved (to aspecific destination IP address). Such connections are typicallyrouted via the proxy using mechanisms such as IP table REDIRECT/eBPF. After performing any routing related transformations, theproxy will forward the connection to the IP address to which theconnection was bound.
STATIC
Use the static IP addresses specified in endpoints (see below) as thebacking instances associated with the service.
DNS
Attempt to resolve the IP address by querying the ambient DNS,during request processing. If no endpoints are specified, the proxywill resolve the DNS address specified in the hosts field, ifwildcards are not used. If endpoints are specified, the DNSaddresses specified in the endpoints will be resolved to determinethe destination IP address. DNS resolution cannot be used with Unixdomain socket endpoints.