--- title: Sidecar description: Configuration affecting network reachability of a sidecar. location: https://istio.io/docs/reference/config/networking/v1alpha3/sidecar.html layout: protoc-gen-docs generator: protoc-gen-docs number_of_entries: 5 ---

`Sidecar` describes the configuration of the sidecar proxy that mediates inbound and outbound communication to the workload instance it is attached to. By default, Istio will program all sidecar proxies in the mesh with the necessary configuration required to reach every workload instance in the mesh, as well as accept traffic on all the ports associated with the workload. The Sidecar resource provides a way to fine tune the set of ports, protocols that the proxy will accept when forwarding traffic to and from the workload. In addition, it is possible to restrict the set of services that the proxy can reach when forwarding outbound traffic from workload instances.

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 resource in a namespace will apply to one or more workload instances in the same namespace, selected using the workloadSelector. In the absence of a workloadSelector, it will apply to all workload instances in the same namespace. When determining the Sidecar resource to be applied to a workload instsance, preference will be given to the resource with a workloadSelector that selects this workload instance, over a Sidecar resource without any workloadSelector.

NOTE: Each namespace can have only one Sidecar resource without any workload selector. The behavior of the system is undefined if more than one selector-less Sidecar resources exist in a given namespace. The behavior of the system is undefined if two or more Sidecar resources with a workload selector select the same workload instance.

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

    apiVersion: networking.istio.io/v1alpha3
    kind: Sidecar
    metadata:
      name: default
      namespace: prod-us1
    spec:
      egress:
      - hosts:
        - "prod-us1/*"
        - "prod-apis/*"
        - "istio-system/*"

The example below declares a Sidecar resource in the prod-us1 namespace that accepts inbound HTTP traffic on port 9080 and forwards it 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.

    apiVersion: networking.istio.io/v1alpha3
    kind: Sidecar
    metadata:
      name: default
      namespace: prod-us1
    spec:
      ingress:
      - port:
          number: 9080
          protocol: HTTP
          name: somename
        defaultEndpoint: unix:///var/run/someuds.sock
      egress:
      - hosts:
        - "istio-system/*"
      - port:
          number: 9080
          protocol: HTTP
          name: egresshttp
        hosts:
        - "prod-us1/*"

If the workload is deployed without IPTables based traffic capture, the Sidecar resource is the only way to configure the ports on the proxy attached to the workload instance. The following example declares a Sidecar resource 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 ISTIOMETAINTERCEPTION_MODE is set to NONE, the specification below allows such pods to receive HTTP traffic on port 9080 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.

    apiVersion: networking.istio.io/v1alpha3
    kind: Sidecar
    metadata:
      name: no-ip-tables
      namespace: prod-us1
    spec:
      workloadSelector:
        labels:
          app: productpage
      ingress:
      - port:
          number: 9080 # binds to 0.0.0.0:9080
          protocol: HTTP
          name: somename
        defaultEndpoint: 127.0.0.1:8080
        captureMode: NONE # not needed if metadata is set for entire proxy
      egress:
      - port:
          number: 3306
          protocol: MYSQL
          name: egressmysql
        captureMode: NONE # not needed if metadata is set for entire proxy
        bind: 127.0.0.1
        hosts:
        - "*/mysql.foo.com"

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

    apiVersion: networking.istio.io/v1alpha3
    kind: ServiceEntry
    metadata:
      name: external-svc-mysql
      namespace: ns1
    spec:
      hosts:
      - mysql.foo.com
      ports:
      - number: 3306
        name: mysql
        protocol: MYSQL
      location: MESH_EXTERNAL
      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 that in this scenario, the ISTIOMETAINTERCEPTION_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.

    apiVersion: networking.istio.io/v1alpha3
    kind: Sidecar
    metadata:
      name: partial-ip-tables
      namespace: prod-us1
    spec:
      workloadSelector:
        labels:
          app: productpage
      ingress:
      - bind: 172.16.1.32
        port:
          number: 80 # binds to 172.16.1.32:80
          protocol: HTTP
          name: somename
        defaultEndpoint: 127.0.0.1:8080
        captureMode: NONE
      egress:
        # use the system detected defaults
        # sets up configuration to handle outbound traffic to services
        # in 192.168.0.0/16 subnet, based on information provided by the
        # service registry
      - captureMode: IPTABLES
        hosts:
        - "*/*"

## CaptureMode

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

Name | Description
--- | ---
`DEFAULT` | The default capture mode defined by the environment
`IPTABLES` | Capture traffic using IPtables redirection
`NONE` | No traffic capture. When used in egress listener, the application is expected to explicitly communicate with the listener port/unix domain socket. When used in ingress listener, care needs to be taken to ensure that the listener port is not in use by other processes on the host.

## IstioEgressListener

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

Field | Type | Description
--- | --- | ---
`port` | `Port` | The port associated with the listener. If using Unix domain socket, use 0 as the port number, with a valid protocol. The port if specified, will be used as the default destination port associated with the imported hosts. If the port is omitted, Istio will infer the listener ports based on the imported hosts. Note that when multiple egress listeners are specified, where one or more listeners have specific ports while others have no port, the hosts exposed on a listener port will be based on the listener with the most specific port.
`bind` | `string` | The ip or the Unix domain socket to which the listener should be bound to. Port MUST be specified if bind is not empty. Format: `x.x.x.x` or `unix:///path/to/uds` or `unix://@foobar` (Linux abstract namespace). If omitted, Istio will automatically configure the defaults based on imported services, the workload instances to which this configuration is applied to and the captureMode. If captureMode is NONE, bind will default to 127.0.0.1.
`captureMode` | `CaptureMode` | When the bind address is an IP, the captureMode option dictates how traffic to the listener is expected to be captured (or not). captureMode must be DEFAULT or NONE for Unix domain socket binds.
`hosts` | `string[]` | REQUIRED: One or more service hosts exposed by the listener in `namespace/dnsName` format. Services in the specified namespace matching `dnsName` will be exposed. The corresponding service can be a service in the service registry (e.g., a Kubernetes or cloud foundry service) or a service specified using a `ServiceEntry` or `VirtualService` configuration. Any associated `DestinationRule` in the same namespace will also be used. The `dnsName` should be specified using FQDN format, optionally including a wildcard character in the left-most component (e.g., `prod/*.example.com`). Set the `dnsName` to `*` to select all services from the specified namespace (e.g.,`prod/*`). The `namespace` can also be set to `*` to select a particular service from any available namespace (e.g., “*/foo.example.com”). NOTE: Only services and configuration artifacts exported to the sidecar’s namespace (e.g., `exportTo` value of `*`) can be referenced. Private configurations (e.g., `exportTo` set to `.`) will not be available. Refer to the `exportTo` setting in `VirtualService`, `DestinationRule`, and `ServiceEntry` configurations for details.

## IstioIngressListener

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

Field | Type | Description
--- | --- | ---
`port` | `Port` | REQUIRED. The port associated with the listener. If using Unix domain socket, use 0 as the port number, with a valid protocol.
`bind` | `string` | The ip or the Unix domain socket to which the listener should be bound to. Format: `x.x.x.x` or `unix:///path/to/uds` or `unix://@foobar` (Linux abstract namespace). If omitted, Istio will automatically configure the defaults based on imported services and the workload instances to which this configuration is applied to.
`captureMode` | `CaptureMode` | When the bind address is an IP, the captureMode option dictates how traffic to the listener is expected to be captured (or not). captureMode must be DEFAULT or NONE for Unix domain socket binds.
`defaultEndpoint` | `string` | REQUIRED: The loopback 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 point on the sidecar to a port or Unix domain socket where the application workload instance is listening for connections. Format should be 127.0.0.1:PORT or `unix:///path/to/socket`

## Sidecar

Field | Type | Description
--- | --- | ---
`workloadSelector` | `WorkloadSelector` | Criteria used to select the specific set of pods/VMs on which this sidecar configuration should be applied. If omitted, the sidecar configuration will be applied to all workload instances in the same namespace.
`ingress` | `IstioIngressListener[]` | Ingress specifies the configuration of the sidecar for processing inbound traffic to the attached workload instance. If omitted, Istio will automatically configure the sidecar based on the information about the workload obtained from the orchestration platform (e.g., exposed ports, services, etc.). If specified, inbound ports are configured if and only if the workload instance is associated with a service.
`egress` | `IstioEgressListener[]` | Egress specifies the configuration of the sidecar for processing outbound traffic from the attached workload instance to other services in the mesh. If omitted, Istio will automatically configure the sidecar to be able to reach every service in the mesh that is visible to this namespace.

## WorkloadSelector

WorkloadSelector specifies the criteria used to determine if the Gateway or Sidecar resource 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.

Field | Type | Description
--- | --- | ---
`labels` | `map<string, string>` | REQUIRED: One or more labels that indicate a specific set of pods/VMs on which this sidecar configuration should be applied. The scope of label search is restricted to the configuration namespace in which the the resource is present.