Istio CNI fails on Docker Desktop arm64 with loopback plugin missing network name

[phmcder]

Bug report

Description

Istio CNI fails to create pod sandboxes on Docker Desktop Kubernetes running on Apple Silicon.

The failure is:

Failed to create pod sandbox:
networkPlugin cni failed to set up pod:
plugin type="loopback" failed (add): missing network name

Cleanup also fails with:

plugin type="loopback" failed (delete): missing network name

This appears related to istio/istio#49208.

Reproduction

1. Enable Kubernetes in Docker Desktop.
2. Install Istio 1.30.3 with Istio CNI enabled.
3. Enable sidecar injection for a namespace.
4. Create an injected pod:

kubectl create namespace istio-cni-smoke

kubectl label namespace istio-cni-smoke \
  istio-injection=enabled \
  pod-security.kubernetes.io/enforce=baseline

kubectl run cni-smoke \
  -n istio-cni-smoke \
  --image=busybox:1.37 \
  --restart=Never \
  --command -- sleep 300

5. Inspect the pod events:

kubectl get events -n istio-cni-smoke --sort-by=.lastTimestamp

Actual behavior

The pod remains stuck during sandbox creation and never receives an IP address.

The event contains:

FailedCreatePodSandBox:
plugin type="loopback" failed (add): missing network name

The pod cannot start even though the istio-cni-node DaemonSet is Ready.

Expected behavior

Istio CNI should configure the pod network successfully and allow the injected pod to start.

The pod should contain istio-proxy but should not require an istio-init container.

Environment

• Host OS: macOS
• Host architecture: Apple Silicon / arm64
• Kubernetes: v1.36.1
• Container runtime: Docker Engine 29.7.2
• Docker Desktop version: v4.86.0
• Istio: 1.30.3
• Kubernetes context: docker-desktop
• Node OS: Docker Desktop
• Node kernel: 6.12.76-linuxkit
• Node architecture: arm64

Istio CNI status

Istio CNI logs reported successful installation and wrote the CNI configuration, but pod sandbox creation still failed in Docker Desktop's loopback plugin.

Workaround

Disabling Istio CNI and using the standard Istio sidecar injector avoids this CNI error, but injected pods require NET_ADMIN and NET_RAW in istio-init, which conflicts with Kubernetes Pod Security Baseline enforcement.

Using kind or minikube is currently the alternative.

Please let me know if additional Docker Desktop diagnostics or Kubernetes CNI configuration is required.

Platform

macOS

Version information

Client:
 Version:           29.7.2
 API version:       1.55
 Go version:        go1.26.5
 Git commit:        a7dcaa6
 Built:             Wed Aug  5 18:27:50 2026
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.86.0 (236216)
 Engine:
  Version:          29.7.2
  API version:      1.55 (minimum version 1.40)
  Go version:       go1.26.5
  Git commit:       6a43e3d
  Built:            Wed Aug  5 18:28:35 2026
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          v2.2.5
  GitCommit:        e53c7c1516c3b2bff98eb76f1f4117477e6f4e66
 runc:
  Version:          1.3.6
  GitCommit:        v1.3.6-0-g491b69ba
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
Client:
 Version:    29.7.2
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  agent: Docker AI Agent Runner (Docker Inc.)
    Version:  v1.119.0
    Path:     /Users/philipmcdermott/.docker/cli-plugins/docker-agent
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.30.0
    Path:     /Users/philipmcdermott/.docker/cli-plugins/docker-ai
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.36.0-desktop.1
    Path:     /Users/philipmcdermott/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.3.1
    Path:     /Users/philipmcdermott/.docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.47
    Path:     /Users/philipmcdermott/.docker/cli-plugins/docker-debug
  desktop: Docker Desktop commands (Docker Inc.)
    Version:  v0.4.3
    Path:     /Users/philipmcdermott/.docker/cli-plugins/docker-desktop
  dhi: CLI for managing Docker Hardened Images (Docker Inc.)
    Version:  v0.0.7
    Path:     /Users/philipmcdermott/.docker/cli-plugins/docker-dhi
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.31
    Path:     /Users/philipmcdermott/.docker/cli-plugins/docker-extension
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     /Users/philipmcdermott/.docker/cli-plugins/docker-init
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  v0.43.3
    Path:     /Users/philipmcdermott/.docker/cli-plugins/docker-mcp
  model: Docker Model Runner (Docker Inc.)
    Version:  v1.2.6
    Path:     /Users/philipmcdermott/.docker/cli-plugins/docker-model
  offload: Docker Offload (Docker Inc.)
    Version:  v0.6.9
    Path:     /Users/philipmcdermott/.docker/cli-plugins/docker-offload
  pass: Docker Pass Secrets Manager Plugin (beta) (Docker Inc.)
    Version:  v0.2.0
    Path:     /Users/philipmcdermott/.docker/cli-plugins/docker-pass
  sandbox: "docker sandbox" is deprecated, use Docker Sandboxes instead (Docker Inc.)
    Version:  v0.13.0
    Path:     /Users/philipmcdermott/.docker/cli-plugins/docker-sandbox
  scout: Docker Scout (Docker Inc.)
    Version:  v1.18.1
    Path:     /Users/philipmcdermott/.docker/scout/docker-scout

Server:
 Containers: 135
  Running: 123
  Paused: 0
  Stopped: 12
 Images: 74
 Server Version: 29.7.2
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Discovered Devices:
  cdi: docker.com/gpu=webgpu
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: e53c7c1516c3b2bff98eb76f1f4117477e6f4e66
 runc version: v1.3.6-0-g491b69ba
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.12.76-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 10
 Total Memory: 23.43GiB
 Name: docker-desktop
 ID: 3fbfd775-541f-4cf8-894d-ca37eba04fab
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=unix:///Users/philipmcdermott/Library/Containers/com.docker.docker/Data/docker-cli.sock
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

Diagnostics ID

No response

[andrewb-ontheinternet]

Thanks for the report. We have a fix in the pipeline. You may be able to fix this in the interim period by editing the local 99-loopback.conf file and adding "name": "lo" property so it conforms to spec.

For example:

• macOS: ~/Library/Containers/com.docker.docker/Data/cni/99-loopback.conf

{
  "cniVersion": "1.0.0",
+ "name": "lo",
  "type": "loopback" 
}

[phmcder]

Thanks for the report. We have a fix in the pipeline. You may be able to fix this in the interim period by editing the local 99-loopback.conf file and adding "name": "lo" property so it conforms to spec.

For example:

• macOS: ~/Library/Containers/com.docker.docker/Data/cni/99-loopback.conf

{
"cniVersion": "1.0.0",

• "name": "lo",
  "type": "loopback"
  }

Thanks @andrewb-ontheinternet, this worked for but then got hit by the issue in istio/istio #54865. I the CNI pod reported the error
Error: failed to start container "install-cni": Error response from daemon: path /var/run/netns is mounted on / but it is not a shared or slave mount

The hack mentioned in the ticket worked by going into the node and marning the mount as shared.

This will be needed to be incoprated into any Docker-Desktop which supports Istio ambient but would represent a reduction in security. Maybe have a toggle to enable support for Istio Ambient so a user knows the implications and are willing to take the risk to support an ambient mesh?

[phmcder]

I have created the issue #629