ICA: Restricted Pod Security Blocks the Istio Init Container

Restricted Pod Security Blocks the Istio Init Container

Your cluster runs Kubernetes 1.28 with Pod Security Admission enforced cluster-wide at the restricted level. Istio 1.21 was installed with the default profile, sidecar injection enabled per namespace, and no CNI plugin. The orders namespace has istio-injection=enabled and has run hundreds of pods successfully for months. After a platform upgrade, new orders pods stay in Init:0/1. kubectl describe pod shows the istio-init container has not started and events mention that the container violates the restricted policy because it requests NET_ADMIN and NET_RAW capabilities and runs as root. Existing running pods are unaffected. The team cannot relax the cluster-wide restricted policy, and they need new pods to get sidecars without granting privileged init containers. istioctl analyze reports no issues because the control plane and existing config are valid.

1. Diagnose the failure and explain why existing pods continue to work. What would you check to confirm the admission chain and the injection method?

Read the worked answer

Pod Security Admission evaluates pods only when they are created. Existing orders pods were admitted before the restricted policy took effect and keep running; new pods are rejected at admission because the injected istio-init container requests NET_ADMIN and NET_RAW and runs as root. The failure happens before the container starts, which is why the pod is stuck in Init:0/1 and the event mentions the restricted policy rather than an application error.

Confirm the chain:

kubectl get ns orders -o yaml to see the pod-security.kubernetes.io/enforce labels.
kubectl describe pod <pending-pod> -n orders to read the admission event and identify istio-init as the violating container.
kubectl get mutatingwebhookconfigurations | grep istio to confirm the sidecar injector webhook is active.
istioctl experimental check-inject -n orders <pod> or the injector logs to confirm injection is adding the init container.
kubectl get daemonset -n istio-system | grep cni to confirm no CNI plugin is installed.

istioctl analyze does not catch this because the Istio configuration is valid; the rejection comes from Kubernetes admission, not from Istio validation.

2. Describe the migration to Istio CNI in this environment, including order of operations and rollback. What changes for pod networking and what should you verify before rolling out orders?

Read the worked answer

Istio CNI removes the need for a privileged init container. The CNI node agent runs as a DaemonSet and programs pod networking on the node when the pod sandbox is created. The sidecar injector must be configured to omit istio-init so the pod no longer requests NET_ADMIN and NET_RAW.

Order of operations:

Install or enable the CNI component with the same revision as the control plane, for example via istioctl install --set components.cni.enabled=true or an IstioOperator overlay. Ensure the injector is configured to use CNI and will not inject the privileged init container.
Verify the istio-cni-node DaemonSet is Ready on every node, including nodes that will schedule orders pods. Check its logs for CNI configuration errors.
Test in a non-production namespace with the same restricted policy: create a pod with injection enabled, confirm it reaches Running with a sidecar, and confirm no istio-init container is present.
Only then restart orders workloads. Do not restart all pods at once; the CNI DaemonSet must stay available.

Rollback: keep the previous IstioOperator configuration. If CNI causes networking failures, restore the previous injector configuration and reinstall without CNI, but expect new pods to fail under restricted PSA until the init container is allowed again. Existing CNI-networked pods continue until restarted. Verify with istioctl proxy-status, a mesh-internal request from the test pod, and kubectl describe pod showing no privileged init container.