Gateway

    For example, the following Gateway configuration sets up a proxy to actas a load balancer exposing port 80 and 9080 (http), 443 (https),9443(https) and port 2379 (TCP) for ingress. The gateway will beapplied to the proxy running on a pod with labels app:my-gateway-controller. While Istio will configure the proxy to listenon these ports, it is the responsibility of the user to ensure thatexternal traffic to these ports are allowed into the mesh.

    The Gateway specification above describes the L4-L6 properties of a loadbalancer. A VirtualService can then be bound to a gateway to controlthe forwarding of traffic arriving at a particular host or gateway port.

    For example, the following VirtualService splits traffic forhttps://uk.bookinfo.com/reviews, ,http://uk.bookinfo.com:9080/reviews, into two versions (prod and qa) ofan internal reviews service on port 9080. In addition, requestscontaining the cookie “user: dev-123” will be sent to special port 7777in the qa version. The same rule is also applicable inside the mesh forrequests to the “reviews.prod.svc.cluster.local” service. This rule isapplicable across ports 443, 9080. Note that http://uk.bookinfo.comgets redirected to (i.e. 80 redirects to 443).

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: VirtualService
    3. metadata:
    4. name: bookinfo-rule
    5. namespace: bookinfo-namespace
    6. spec:
    7. hosts:
    8. - reviews.prod.svc.cluster.local
    9. - uk.bookinfo.com
    10. - eu.bookinfo.com
    11. gateways:
    12. - some-config-namespace/my-gateway
    13. - mesh # applies to all the sidecars in the mesh
    14. http:
    15. - match:
    16. - headers:
    17. cookie:
    18. route:
    19. - destination:
    20. port:
    21. number: 7777
    22. host: reviews.qa.svc.cluster.local
    23. - match:
    24. - uri:
    25. prefix: /reviews/
    26. route:
    27. - destination:
    28. port:
    29. number: 9080 # can be omitted if it's the only port for reviews
    30. host: reviews.prod.svc.cluster.local
    31. weight: 80
    32. - destination:
    33. host: reviews.qa.svc.cluster.local
    34. weight: 20

    It is possible to restrict the set of virtual services that can bind toa gateway server using the namespace/hostname syntax in the hosts field.For example, the following Gateway allows any virtual service in the ns1namespace to bind to it, while restricting only the virtual service withfoo.bar.com host in the ns2 namespace to bind to it.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: Gateway
    3. metadata:
    4. name: my-gateway
    5. namespace: some-config-namespace
    6. spec:
    7. app: my-gateway-controller
    8. servers:
    9. - port:
    10. number: 80
    11. name: http
    12. hosts:
    13. - "ns1/*"
    14. - "ns2/foo.bar.com"

    Gateway describes a load balancer operating at the edge of the meshreceiving incoming or outgoing HTTP/TCP connections.

    Port

    Port describes the properties of a specific port of a service.

    FieldTypeDescriptionRequired
    numberuint32A valid non-negative integer port number.Yes
    protocolstringThe protocol exposed on the port.MUST BE one of HTTP|HTTPS|GRPC|HTTP2|MONGO|TCP|TLS.TLS implies the connection will be routed based on the SNI header tothe destination without terminating the TLS connection.Yes
    namestringLabel assigned to the port.No

    Another example

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: Gateway
    3. metadata:
    4. name: my-tcp-ingress
    5. spec:
    6. selector:
    7. app: my-tcp-ingress-gateway
    8. servers:
    9. - port:
    10. number: 27018
    11. name: mongo
    12. protocol: MONGO
    13. hosts:
    14. - "*"

    The following is an example of TLS configuration for port 443

    Server.TLSOptions

    FieldTypeDescriptionRequired
    httpsRedirectboolIf set to true, the load balancer will send a 301 redirect for allhttp connections, asking the clients to use HTTPS.No
    modeTLSmodeOptional: Indicates whether connections to this port should besecured using TLS. The value of this field determines how TLS isenforced.No
    serverCertificatestringREQUIRED if mode is SIMPLE or MUTUAL. The path to the fileholding the server-side TLS certificate to use.No
    privateKeystringREQUIRED if mode is SIMPLE or MUTUAL. The path to the fileholding the server’s private key.No
    caCertificatesstringREQUIRED if mode is MUTUAL. The path to a file containingcertificate authority certificates to use in verifying a presentedclient side certificate.No
    credentialNamestringThe credentialName stands for a unique identifier that can be usedto identify the serverCertificate and the privateKey. ThecredentialName appended with suffix “-cacert” is used to identifythe CaCertificates associated with this server. Gateway workloadscapable of fetching credentials from a remote credential store suchas Kubernetes secrets, will be configured to retrieve theserverCertificate and the privateKey using credentialName, insteadof using the file system paths specified above. If using mutual TLS,gateway workload instances will retrieve the CaCertificates usingcredentialName-cacert. The semantics of the name are platformdependent. In Kubernetes, the default Istio supplied credentialserver expects the credentialName to match the name of theKubernetes secret that holds the server certificate, the privatekey, and the CA certificate (if using mutual TLS). Set theISTIO_META_USER_SDS metadata variable in the gateway’s proxy toenable the dynamic credential fetching feature.No
    subjectAltNamesstring[]A list of alternate names to verify the subject identity in thecertificate presented by the client.No
    verifyCertificateSpkistring[]An optional list of base64-encoded SHA-256 hashes of the SKPIs ofauthorized client certificates.Note: When both verify_certificate_hash and verify_certificate_spkiare specified, a hash matching either value will result in thecertificate being accepted.No
    verifyCertificateHashstring[]An optional list of hex-encoded SHA-256 hashes of theauthorized client certificates. Both simple and colon separatedformats are acceptable.Note: When both verify_certificate_hash and verify_certificate_spkiare specified, a hash matching either value will result in thecertificate being accepted.No
    minProtocolVersionOptional: Minimum TLS protocol version.No
    maxProtocolVersionTLSProtocolOptional: Maximum TLS protocol version.No
    cipherSuitesstring[]Optional: If specified, only support the specified cipher list.Otherwise default to the default cipher list supported by Envoy.No

    TLS protocol versions.

    Server.TLSOptions.TLSmode

    NameDescription
    PASSTHROUGHThe SNI string presented by the client will be used as the matchcriterion in a VirtualService TLS route to determine thedestination service from the service registry.
    SIMPLESecure connections with standard TLS semantics.
    MUTUALSecure connections to the downstream using mutual TLS by presentingserver certificates for authentication.
    AUTO_PASSTHROUGHSimilar to the passthrough mode, except servers with this TLS modedo not require an associated VirtualService to map from the SNIvalue to service in the registry. The destination details such asthe service/subset/port are encoded in the SNI value. The proxywill forward to the upstream (Envoy) cluster (a group ofendpoints) specified by the SNI value. This server is typicallyused to provide connectivity between services in disparate L3networks that otherwise do not have direct connectivity betweentheir respective endpoints. Use of this mode assumes that both thesource and the destination are using Istio mTLS to secure traffic.
    ISTIO_MUTUALSecure connections from the downstream using mutual TLS by presentingserver certificates for authentication.Compared to Mutual mode, this mode uses certificates, representinggateway workload identity, generated automatically by Istio formTLS authentication. When this mode is used, all other fields inTLSOptions should be empty.