How Does Istio Automatically Inject Sidecars and Intercept Traffic?

Background

When Istio is installed in a cluster, adding the label istio-injection=enabled to a namespace causes every pod in that namespace to be injected with an Istio sidecar proxy; existing pods need a restart, while newly created pods are injected automatically.

Sidecar Container Injection

When a pod creation request reaches the kube‑apiserver, after authentication and admission control the server calls the sidecar‑injector webhook (provided by istiod) to add an init container and the istio-proxy container before persisting the pod object to etcd.

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: istio-revision-tag-default
webhooks:
  - admissionReviewVersions:
    - v1beta1
    - v1
    clientConfig:
      caBundle: xxx
      service:
        name: istiod
        namespace: istio-system
        path: /inject
        port: 443
    failurePolicy: Fail
    matchPolicy: Equivalent
    name: namespace.sidecar-injector.istio.io
    namespaceSelector:
      matchExpressions:
      - key: istio-injection
        operator: In
        values:
        - enabled
    rules:
    - apiGroups:
      - ""
      apiVersions:
      - v1
      operations:
      - CREATE
      resources:
      - pods
      scope: '*'

The webhook is compiled into the istiod process from Istio 1.5 onward and applies to pods in namespaces labeled istio-injection=enabled.

Business pods are automatically injected with the istio-init container and the istio-proxy container.

# initContainer configuration (sets up iptables)
initContainers:
  - name: istio-init
    image: docker.io/istio/proxyv2:1.19.0
    args:
      - istio-iptables
      - '-p'
      - '15001'
      - '-z'
      - '15006'
      - '-u'
      - '1337'
      - '-m'
      - REDIRECT
      - '-i'
      - '*'
      - '-x'
      - ''
      - '-b'
      - '*'
      - '-d'
      - 15090,15021,15020
      - '--log_output_level=default:info'
    securityContext:
      capabilities:
        add:
          - NET_ADMIN
          - NET_RAW
        drop:
          - ALL
# istio-proxy container configuration
containers:
  - name: istio-proxy
    image: docker.io/istio/proxyv2:1.19.0
    args:
      - proxy
      - sidecar
      - '--domain'
      - $(POD_NAMESPACE).svc.cluster.local
      - '--proxyLogLevel=warning'
      - '--proxyComponentLogLevel=misc:error'
      - '--log_output_level=default:info'
    ports:
      - name: http-envoy-prom
        containerPort: 15090
        protocol: TCP
    env: []
    volumeMounts:
      - name: workload-socket
        mountPath: /var/run/secrets/workload-spiffe-uds
      - name: credential-socket
        mountPath: /var/run/secrets/credential-uds
      - name: workload-certs
        mountPath: /var/run/secrets/workload-spiffe-credentials
      - name: istiod-ca-cert
        mountPath: /var/run/secrets/istio
      - name: istio-data
        mountPath: /var/lib/istio/data
      - name: istio-envoy
        mountPath: /etc/istio/proxy
      - name: istio-token
        mountPath: /var/run/secrets/tokens
      - name: istio-podinfo
        mountPath: /etc/istio/pod
      - name: kube-api-access-xsnpl
        readOnly: true
        mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    securityContext:
      runAsUser: 1337
      runAsGroup: 1337

Istio Interception Principle

After sidecar injection, all network traffic to and from the pod is transparently intercepted by the sidecar using iptables rules. The interception consists of two parts: the istio-init container sets up iptables forwarding to the sidecar, and the istio-proxy container (Envoy) actually processes the traffic.

3.1 istio‑init Container Analysis

The init container runs the istio-iptables command to configure iptables and then exits.

istio-iptables -p 15001 -z 15006 -u 1337 -m REDIRECT -i '*' -x '' -b '*' -d 15090,15021,15020

This command redirects all inbound traffic (except ports 15090, 15021, 15020) to port 15006 of the sidecar and redirects all outbound traffic to port 15001, while excluding the sidecar’s own UID (1337) from being redirected.

-z 15006: forward inbound traffic to the sidecar’s port 15006.

-u 1337: exclude UID 1337 (the sidecar) from redirection.

-m REDIRECT: use DNAT REDIRECT.

-p 15001: redirect outbound traffic to the sidecar’s port 15001.

-d 15090,15021,15020: exclude telemetry and health‑check ports.

-i '*': apply to all interfaces.

-x '': no IP exclusions.

-b '*': apply to all inbound traffic.

3.2 Sidecar Interception Rule Analysis

The sidecar shares the pod’s network namespace; its iptables rules affect the application’s packet flow.

# iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N ISTIO_INBOUND
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT
-A PREROUTING -p tcp -j ISTIO_INBOUND
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_INBOUND -p tcp -m tcp --dport 15008 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15090 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15021 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15020 -j RETURN
-A ISTIO_INBOUND -p tcp -j ISTIO_IN_REDIRECT
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006
-A ISTIO_OUTPUT -s 127.0.0.6/32 -o lo -j RETURN
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -p tcp -m tcp ! --dport 15008 -m owner --uid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -o lo -m owner ! --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -p tcp -m tcp ! --dport 15008 -m owner --gid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -o lo -m owner ! --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001

-P PREROUTING ACCEPT: default accept policy.

-N ISTIO_INBOUND: create custom chain for inbound traffic.

-A PREROUTING -p tcp -j ISTIO_INBOUND: send all TCP traffic to the inbound chain.

-A ISTIO_INBOUND -p tcp -j ISTIO_IN_REDIRECT: redirect non‑excluded inbound traffic to port 15006.

-A ISTIO_OUTPUT -j ISTIO_REDIRECT: redirect outbound traffic to port 15001.

3.2.1 Inbound Traffic Rule Details

Inbound traffic (from outside the pod) is first processed by the PREROUTING chain, then jumps to ISTIO_INBOUND. If the destination port is not one of the excluded ports (15008, 15090, 15020, 15021), the packet is redirected to ISTIO_IN_REDIRECT and finally DNAT‑ed to port 15006 where Envoy processes it. After processing, traffic destined for the application container is allowed to pass (RETURN rule for UID 1337).

3.2.1 Outbound Traffic Rule Details

Outbound traffic from the application container is sent to the OUTPUT chain, then to ISTIO_OUTPUT. Non‑local traffic is redirected to ISTIO_REDIRECT and DNAT‑ed to port 15001, where Envoy intercepts it. Packets generated by the sidecar itself (UID 1337) are exempted by RETURN rules.

3.3 How to Allow Specific Traffic to Bypass Envoy

To prevent interception for certain destinations, add RETURN rules to the ISTIO_OUTPUT chain, for example to exclude port 8080 and the 172.16.2.0/24 subnet.

-A ISTIO_OUTPUT -p tcp -m tcp --dport 8080 -j RETURN
-A ISTIO_OUTPUT -d 172.16.2.0/24 -j RETURN

Istio also supports pod annotations to control interception:

traffic.sidecar.istio.io/excludeOutboundPorts: <span>8080</span>
traffic.sidecar.istio.io/excludeOutboundIPRanges: <span>172.16.2.0/24</span>

Viewing the rules inside a pod with iptables -t nat -L -nv shows the added RETURN entries in ISTIO_OUTPUT.