Istio can program a pod's traffic-capture rules either with an injected `istio-init` container or with the Istio CNI plugin. What does each approach do, and what changes about pod privileges and pod startup when you switch to the CNI plugin?
answer
- same rules, different writer
- capabilities in every pod spec
- privilege moves to a node DaemonSet
- restricted Pod Security Standard rejects it
- a pod can start before the node plugin is ready
basics
~20 sThe istio-init container writes the pod's redirection rules from inside the pod, which requires NET_ADMIN and NET_RAW on every workload. The Istio CNI plugin writes the same rules from a node-level DaemonSet during pod network setup, so workload pods need no elevated capabilities.
solid answer
~50 sBoth produce the same result — redirection rules in the pod's network namespace — but from different places. With the default approach Istio injects an `istio-init` container that runs before your app and programs those rules itself; because it manipulates the network namespace it needs the `NET_ADMIN` and `NET_RAW` capabilities, which every meshed pod then carries in its spec. That is what collides with a restricted Pod Security Standard or an admission policy banning added capabilities. The Istio CNI plugin moves the work to a node-level component (`istio-cni-node`) that runs as part of pod network setup, before any container starts. Workload pods drop the elevated capabilities and the extra init container entirely. The cost is a new ordering dependency: the plugin must be installed and chained correctly in the node's CNI configuration, and a pod scheduled onto a node where it is not yet ready can start without capture. Istio's `istio-validation` init container exists to catch exactly that.
go deeper
Know that something has to program the pod's redirection rules before the app starts, and that Istio does it either with an init container in the pod or with a plugin on the node.
Name the capabilities istio-init requires, explain that the CNI plugin does the same work during pod network setup, and state what disappears from the pod spec as a result.
Discuss the ordering hazard the CNI path introduces, how a pod scheduled before the node agent is ready silently bypasses the mesh, and the validation init container that surfaces it.
Frame this as where network privilege lives across the fleet: thousands of capability-bearing pods versus one node-scoped privileged agent, and what change control and Pod Security policy each shape demands.
## The same rules, written by two different actors Istio's transparent capture depends on redirection rules inside the pod's network namespace: outbound connections from the application go to the sidecar's outbound port, inbound connections go to its inbound port, and traffic from the proxy's own UID is exempted so it does not loop. Nothing about the mesh's behaviour depends on *who* writes those rules — only on their being present before the application's first packet. **Path one: the `istio-init` container.** The injection webhook adds an init container that runs to completion before the application container starts. It configures the redirection and exits. Because writing those rules means manipulating the network namespace, the container requests `NET_ADMIN` and `NET_RAW`. Those capabilities appear in the pod spec of every meshed workload. **Path two: the Istio CNI plugin.** A DaemonSet (`istio-cni-node`) installs a plugin into the node's CNI configuration and runs privileged on the node. When the pod's network is being set up — before any of its containers exist — the plugin writes the same rules from outside. The injected pod then contains only `istio-proxy` and your application. ## What actually changes for you **Pod privileges.** This is the headline. With `istio-init`, every application pod's spec carries capabilities that a security reviewer will question and that a namespace enforcing the restricted Pod Security Standard will reject outright, because that profile forbids adding capabilities beyond `NET_BIND_SERVICE`. Teams then face a bad choice: exempt every meshed namespace from the profile, or give up the mesh. The CNI plugin removes the dilemma by concentrating the privilege in one audited DaemonSet on the node instead of spreading it across thousands of workload pods. It is worth being precise: the privilege does not disappear, it moves — and it moves to a component with node-wide reach, which is its own security conversation. **Startup shape.** `istio-init` is self-contained: if it ran, the rules are there, and Kubernetes' own init-container ordering guarantees it ran before the app. The CNI path has no such intra-pod guarantee, because the work happens before the pod's containers exist. If a pod is scheduled onto a node whose `istio-cni-node` has not finished installing or reloading its configuration, the pod can start with no capture at all — traffic bypasses the mesh silently. This is most visible right after a node joins, after a node reboot, or during a cluster upgrade that cycles nodes. Istio's response is an `istio-validation` init container that checks the redirection is actually in place and fails the pod if it is not, converting a silent bypass into a visible crash-loop. **Interaction with other plugins.** The plugin has to be chained into the node's existing CNI configuration alongside whatever provides pod networking. Ordering and file-name conventions matter here, and a misconfigured chain is a cluster-wide problem rather than a per-pod one. That is the practical reason some platform teams stay on `istio-init` in small clusters: it is per-pod, self-evident, and its failure mode is contained. ## Choosing between them ```yaml # What a meshed pod's spec no longer needs once the CNI plugin is in use initContainers: - name: istio-init # <- absent with the CNI plugin securityContext: capabilities: add: ["NET_ADMIN", "NET_RAW"] ``` Use the CNI plugin when workload pods must satisfy a restricted security profile, when an admission policy forbids added capabilities, or when you simply do not want thousands of pods declaring network privileges. Stay with `istio-init` when you control a small cluster, cannot install node-level components, or your CNI stack makes chaining risky. Ambient mode makes the question moot for meshed workloads in a different way, since there is no per-pod sidecar to redirect into. ## The interview signal The weak answer treats this as a configuration toggle. The strong answer identifies it as a privilege-placement decision — the same capability, held by every workload versus by one node agent — and names the ordering hazard the move introduces, along with the validation container that exists precisely because that hazard is real.
- If the CNI plugin is not ready when a pod starts, what does the failure look like?The pod comes up with no redirection: the app runs, but its traffic bypasses the proxy entirely — no mTLS, no policy, no mesh telemetry, and no error anywhere. That silence is why Istio ships the istio-validation init container, which checks the rules are present and fails the pod when they are not, turning an invisible bypass into an obvious crash-loop.
- Does moving to the CNI plugin actually reduce privilege in the cluster?It relocates it. Workload pods stop declaring NET_ADMIN and NET_RAW, which is a genuine win for blast radius and for passing a restricted Pod Security Standard. But the node DaemonSet is privileged and node-scoped, so you have traded many low-reach grants for one high-reach one that needs stronger review and change control.
saying these in an interview costs you the question
- Claims the CNI plugin eliminates privilege rather than relocating it
- Thinks istio-init and the CNI plugin produce different capture behaviour
- Ignores that istio-init capabilities break restricted Pod Security Standards
- Assumes the node plugin is always ready before any pod starts
- Believes the init container keeps running alongside the app