Sidecar

    Services and configuration in a mesh are organized into one or more namespaces (e.g., a Kubernetes namespace or a CF org/space). A Sidecar configuration in a namespace will apply to one or more workload instances in the same namespace, selected using the workloadSelector field. In the absence of a workloadSelector, it will apply to all workload instances in the same namespace. When determining the Sidecar configuration to be applied to a workload instance, preference will be given to the resource with a workloadSelector that selects this workload instance, over a Sidecar configuration without any workloadSelector.

    NOTE 1: *Each namespace can have only one Sidecar configuration without any workloadSelector that specifies the default for all pods in that namespace*. It is recommended to use the name default for the namespace-wide sidecar. The behavior of the system is undefined if more than one selector-less Sidecar configurations exist in a given namespace. The behavior of the system is undefined if two or more Sidecar configurations with a workloadSelector select the same workload instance.

    NOTE 2: A Sidecar configuration in the MeshConfig root namespace will be applied by default to all namespaces without a Sidecar configuration. This global default Sidecar configuration should not have any workloadSelector.

    The example below declares a global default Sidecar configuration in the root namespace called istio-config, that configures sidecars in all namespaces to allow egress traffic only to other workloads in the same namespace as well as to services in the istio-system namespace.

    1. apiVersion: networking.istio.io/v1beta1
    2. kind: Sidecar
    3. metadata:
    4.   name: default
    5.   namespace: istio-config
    6. spec:
    7.   egress:
    8.   - hosts:
    9.     - "./*"
    10.     - "istio-system/*"

    The example below declares a Sidecar configuration in the prod-us1 namespace that overrides the global default defined above, and configures the sidecars in the namespace to allow egress traffic to public services in the prod-us1, prod-apis, and the istio-system namespaces.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: Sidecar
    3. metadata:
    4.   name: default
    5.   namespace: prod-us1
    6. spec:
    7.   egress:
    8.   - hosts:
    9.     - "prod-us1/*"
    10.     - "prod-apis/*"
    11.     - "istio-system/*"
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: Sidecar
    3. metadata:
    4.   name: default
    5.   namespace: prod-us1
    6. spec:
    7.   egress:
    8.   - hosts:
    9.     - "prod-us1/*"
    10.     - "prod-apis/*"
    11.     - "istio-system/*"

    The following example declares a Sidecar configuration in the prod-us1 namespace for all pods with labels app: ratings belonging to the ratings.prod-us1 service. The workload accepts inbound HTTP traffic on port 9080. The traffic is then forwarded to the attached workload instance listening on a Unix domain socket. In the egress direction, in addition to the istio-system namespace, the sidecar proxies only HTTP traffic bound for port 9080 for services in the prod-us1 namespace.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: Sidecar
    3. metadata:
    4.   name: ratings
    5.   namespace: prod-us1
    6. spec:
    7.   workloadSelector:
    8.     labels:
    9.       app: ratings
    10.   ingress:
    11.   - port:
    12.       number: 9080
    13.       protocol: HTTP
    14.       name: somename
    15.     defaultEndpoint: unix:///var/run/someuds.sock
    16.   egress:
    17.   - port:
    18.       number: 9080
    19.       protocol: HTTP
    20.       name: egresshttp
    21.     hosts:
    22.     - "prod-us1/*"
    23.   - hosts:
    24.     - "istio-system/*"

    If the workload is deployed without IPTables-based traffic capture, the Sidecar configuration is the only way to configure the ports on the proxy attached to the workload instance. The following example declares a Sidecar configuration in the prod-us1 namespace for all pods with labels app: productpage belonging to the productpage.prod-us1 service. Assuming that these pods are deployed without IPtable rules (i.e. the istio-init container) and the proxy metadata ISTIO_META_INTERCEPTION_MODE is set to NONE, the specification, below, allows such pods to receive HTTP traffic on port 9080 (wrapped inside Istio mutual TLS) and forward it to the application listening on 127.0.0.1:8080. It also allows the application to communicate with a backing MySQL database on 127.0.0.1:3306, that then gets proxied to the externally hosted MySQL service at mysql.foo.com:3306.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: Sidecar
    3. metadata:
    4.   name: no-ip-tables
    5.   namespace: prod-us1
    6. spec:
    7.   workloadSelector:
    8.       app: productpage
    9.   ingress:
    10.   - port:
    11.       number: 9080 # binds to proxy_instance_ip:9080 (0.0.0.0:9080, if no unicast IP is available for the instance)
    12.       protocol: HTTP
    13.       name: somename
    14.     defaultEndpoint: 127.0.0.1:8080
    15.     captureMode: NONE # not needed if metadata is set for entire proxy
    16.   egress:
    18.       number: 3306
    19.       protocol: MYSQL
    20.       name: egressmysql
    21.     captureMode: NONE # not needed if metadata is set for entire proxy
    22.     bind: 127.0.0.1
    23.     hosts:
    24.     - "*/mysql.foo.com"
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: Sidecar
    3. metadata:
    4.   name: no-ip-tables
    5.   namespace: prod-us1
    6. spec:
    7.   workloadSelector:
    8.     labels:
    9.       app: productpage
    10.   ingress:
    11.   - port:
    12.       number: 9080 # binds to proxy_instance_ip:9080 (0.0.0.0:9080, if no unicast IP is available for the instance)
    13.       protocol: HTTP
    14.       name: somename
    15.     defaultEndpoint: 127.0.0.1:8080
    16.     captureMode: NONE # not needed if metadata is set for entire proxy
    17.   egress:
    18.   - port:
    19.       number: 3306
    20.       protocol: MYSQL
    21.       name: egressmysql
    22.     captureMode: NONE # not needed if metadata is set for entire proxy
    23.     bind: 127.0.0.1
    24.     hosts:
    25.     - "*/mysql.foo.com"

    And the associated service entry for routing to mysql.foo.com:3306

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: ServiceEntry
    3. metadata:
    4.   name: external-svc-mysql
    5.   namespace: ns1
    6. spec:
    7.   hosts:
    8.   - mysql.foo.com
    9.   ports:
    10.   - number: 3306
    11.     name: mysql
    12.     protocol: MYSQL
    13.   location: MESH_EXTERNAL
    14.   resolution: DNS
    1. apiVersion: networking.istio.io/v1beta1
    2. kind: ServiceEntry
    3. metadata:
    4.   name: external-svc-mysql
    5.   namespace: ns1
    6. spec:
    7.   hosts:
    8.   - mysql.foo.com
    9.   ports:
    10.   - number: 3306
    11.     name: mysql
    12.     protocol: MYSQL
    13.   location: MESH_EXTERNAL
    14.   resolution: DNS

    It is also possible to mix and match traffic capture modes in a single proxy. For example, consider a setup where internal services are on the 192.168.0.0/16 subnet. So, IP tables are setup on the VM to capture all outbound traffic on 192.168.0.0/16 subnet. Assume that the VM has an additional network interface on 172.16.0.0/16 subnet for inbound traffic. The following Sidecar configuration allows the VM to expose a listener on 172.16.1.32:80 (the VM’s IP) for traffic arriving from the 172.16.0.0/16 subnet.

    NOTE: The ISTIO_META_INTERCEPTION_MODE metadata on the proxy in the VM should contain REDIRECT or TPROXY as its value, implying that IP tables based traffic capture is active.

    1. kind: Sidecar
    2. metadata:
    3.   name: partial-ip-tables
    4.   namespace: prod-us1
    5. spec:
    6.   workloadSelector:
    7.     labels:
    8.       app: productpage
    9.   ingress:
    10.   - bind: 172.16.1.32
    11.     port:
    12.       number: 80 # binds to 172.16.1.32:80
    13.       protocol: HTTP
    14.       name: somename
    15.     defaultEndpoint: 127.0.0.1:8080
    16.     captureMode: NONE
    17.   egress:
    18.     # use the system detected defaults
    19.     # sets up configuration to handle outbound traffic to services
    20.     # in 192.168.0.0/16 subnet, based on information provided by the
    21.     # service registry
    22.   - captureMode: IPTABLES
    23.     hosts:
    24.     - "*/*"

    The following example declares a Sidecar configuration in the prod-us1 namespace for all pods with labels app: ratings belonging to the ratings.prod-us1 service. The service accepts inbound HTTPS traffic on port 8443 and the sidecar proxy terminates one way TLS using the given server certificates. The traffic is then forwarded to the attached workload instance listening on a Unix domain socket. It is expected that PeerAuthentication policy would be configured in order to set mTLS mode to “DISABLE” on specific ports. In this example, the mTLS mode is disabled on PORT 80. This feature is currently experimental.

    1. apiVersion: networking.istio.io/v1alpha3
    2. kind: Sidecar
    3. metadata:
    4.   name: ratings
    5.   namespace: prod-us1
    6. spec:
    7.   workloadSelector:
    8.     labels:
    9.       app: ratings
    10.   ingress:
    11.   - port:
    12.       number: 80
    13.       protocol: HTTPS
    14.       name: somename
    15.     defaultEndpoint: unix:///var/run/someuds.sock
    16.     tls:
    17.       mode: SIMPLE
    18.       privateKey: "/etc/certs/privatekey.pem"
    1. apiVersion: v1
    2. kind: Service
    3. metadata:
    4.   name: ratings
    5.   labels:
    6.     app: ratings
    7.     service: ratings
    8. spec:
    9.   ports:
    10.   - port: 8443
    11.     name: https
    12.     targetPort: 80
    13.   selector:
    14.     app: ratings
    1. apiVersion: security.istio.io/v1beta1
    2. kind: PeerAuthentication
    3. metadata:
    4.   name: ratings-peer-auth
    5.   namespace: prod-us1
    6. spec:
    7.   selector:
    8.     matchLabels:
    9.       app: ratings
    10.   mtls:
    11.     mode: STRICT
    12.   portLevelMtls:
    13.     80:

    Sidecar describes the configuration of the sidecar proxy that mediates inbound and outbound communication of the workload instance to which it is attached.

    IstioIngressListener

    IstioIngressListener specifies the properties of an inbound traffic listener on the sidecar proxy attached to a workload instance.

    FieldTypeDescriptionRequired
    portPort

    The port associated with the listener.

    		Yes
    bindstring

    The IP to which the listener should be bound. Must be in the format x.x.x.x. Unix domain socket addresses are not allowed in the bind field for ingress listeners. If omitted, Istio will automatically configure the defaults based on imported services and the workload instances to which this configuration is applied to.

    		No
    captureMode

    The captureMode option dictates how traffic to the listener is expected to be captured (or not).

    		No
    defaultEndpointstring

    The IP endpoint or Unix domain socket to which traffic should be forwarded to. This configuration can be used to redirect traffic arriving at the bind IP:Port on the sidecar to a localhost:port or Unix domain socket where the application workload instance is listening for connections. Arbitrary IPs are not supported. Format should be one of 127.0.0.1:PORT, 0.0.0.0:PORT (which will forward to the instance IP), or unix:///path/to/socket

    		Yes

    IstioEgressListener specifies the properties of an outbound traffic listener on the sidecar proxy attached to a workload instance.

    WorkloadSelector

    WorkloadSelector specifies the criteria used to determine if the Gateway, Sidecar, EnvoyFilter, ServiceEntry, or DestinationRule configuration can be applied to a proxy. The matching criteria includes the metadata associated with a proxy, workload instance info such as labels attached to the pod/VM, or any other info that the proxy provides to Istio during the initial handshake. If multiple conditions are specified, all conditions need to match in order for the workload instance to be selected. Currently, only label based selection mechanism is supported.

    FieldTypeDescriptionRequired
    labelsmap<string, string>

    One or more labels that indicate a specific set of pods/VMs on which the configuration should be applied. The scope of label search is restricted to the configuration namespace in which the the resource is present.

    		Yes

    OutboundTrafficPolicy sets the default behavior of the sidecar for handling outbound traffic from the application. If your application uses one or more external services that are not known apriori, setting the policy to ALLOW_ANY will cause the sidecars to route any unknown traffic originating from the application to its requested destination. Users are strongly encouraged to use ServiceEntry configurations to explicitly declare any external dependencies, instead of using ALLOW_ANY, so that traffic to these services can be monitored.

    OutboundTrafficPolicy.Mode

    NameDescription
    REGISTRY_ONLY

    Outbound traffic will be restricted to services defined in the service registry as well as those defined through ServiceEntry configurations.

    ALLOW_ANY

    Outbound traffic to unknown destinations will be allowed, in case there are no services or ServiceEntry configurations for the destination port.

    CaptureMode describes how traffic to a listener is expected to be captured. Applicable only when the listener is bound to an IP.