Fixes agent-substrate#2917. ## Problem `ate-setup setup csi nfs` (and `--setup-csi=nfs|both`) patched the `csi-nfs-controller` Deployment with a privileged `socat` sidecar that exposed the driver's controller socket as plaintext, unauthenticated TCP: `csi-nfs-controller.kube-system.svc:50052`, and `<node>:10000` since the pod is host-networked. Anything with cluster network access could call `CreateVolume` / `DeleteVolume`. ## Change - **Envoy mTLS proxy for the NFS controller**, matching the hostpath driver and `docs/csi-deployment.md`: the sidecar terminates TLS with a serving certificate from `servicednssigner`, requires a client certificate, and accepts only the `ate-api-server` pod identity SPIFFE ID (rendered from the install namespace via `installdefaults.SPIFFEID`). It proxies raw TCP to `/csi/csi.sock`, so gRPC streams are passed end to end with no HTTP route timeout that could cut a slow `CreateVolume` short. No admin port, since the pod runs on the host network. - **`CSIDriverConfig` `nfs.csi.k8s.io`** now sets `tls: {enabled, usePodIdentity, serverName: csi-nfs-controller.kube-system.svc}`. The `.svc` form is the only DNS name `servicednssigner` issues. - **Ordering**: the Service and the Envoy ConfigMap are created before the driver, because the signer refuses to issue a certificate for a pod no Service selects yet (same rule the hostpath step already follows). - **Not privileged**: the proxy runs as root because the driver creates the socket mode 0755, but with `allowPrivilegeEscalation: false`, all capabilities dropped and a read-only root filesystem. The hostpath driver's Envoy loses `privileged: true` the same way. - **Upgrade path**: the patch carries a `$patch: delete` for the `socat` container. The upstream manifest is server-side applied, which leaves containers another field manager added in place, so re-running setup on a cluster that still has the old sidecar removes it. - **Readiness probe** on the proxy, so the Deployment rollout and the Service only count the pod once Envoy has its certificate and is accepting connections. - `hack/setup-csi-nfs-kind.sh` makes the same changes; `docs/csi-deployment.md` gets the `.svc` server name (the example previously named `.svc.cluster.local`, which fails verification), the Service-before-pod note, and a non-privileged security context in the example. ## Verification on kind `ate-setup setup csi both` and `hack/setup-csi-nfs-kind.sh` were run against a kind cluster, including over an install that still had the `socat` sidecar: - `csi-nfs-controller` runs 6/6 with `envoy` in place of `socat`, security context `{runAsUser: 0, allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, capabilities: {drop: [ALL]}}`; the hostpath proxy runs with the same context. - Issued serving certificate SAN: `DNS:csi-nfs-controller.kube-system.svc`. - TLS client without a certificate: `tlsv13 alert certificate required`. Client with a certificate for a different service account: `alert certificate unknown`. Plaintext: no bytes returned. - A gRPC client holding the `ate-api-server` pod identity, using the same TLS settings as `internal/volume/csi` (TLS 1.3, ALPN h2, servicedns trust bundle, server name from the `CSIDriverConfig`), completed `GetPluginInfo`, `ControllerGetCapabilities`, `CreateVolume` and `DeleteVolume` through the proxy. The same client with server name `csi-nfs-controller.kube-system.svc.cluster.local` fails verification, which is why the doc example changed. Not run here: the external-volume e2e suite. The local Docker VM lost outbound network partway through, so atelet could not fetch the gVisor release and no worker could host the probe actor; the suite failed before reaching volumes. CI runs it.

Commits

Commits on Oct 20, 2026

Commits on Oct 21, 2026