Summary
The driver communicates with provider plugins over unauthenticated Unix domain sockets in a shared hostPath directory. The provider_client.go explicitly notes that "the interface is only secured through filesystem ACLs."
This means any process on the node that can access the socket file can send Mount requests to the provider. While filesystem permissions and Pod Security Standards provide layers of defense, adding protocol-level authentication between the driver and provider would provide defense-in-depth.
Proposal
Add an authentication mechanism to the driver-provider gRPC communication so providers can verify the caller is the legitimate CSI driver. Possible approaches:
- mTLS on the Unix socket — driver and provider exchange certificates at startup. Providers reject connections without a valid client certificate.
- Shared secret/token — driver passes a per-node secret (e.g., from a projected volume) in gRPC metadata that the provider validates.
Context
- All providers (AWS, GCP, Azure) currently rely solely on filesystem ACLs for socket security
- The Azure provider has already hardened socket permissions to 0700
- The AWS provider has similarly restricted socket permissions (#637)
- These are valuable hardening steps but do not fully authenticate the caller at the protocol level
Constraints
SO_PEERCRED (PID-based checks) is not viable because the driver and provider run in separate PID namespaces, causing the PID to resolve to 0SO_PEERCRED UID checks are also insufficient when both the driver and potential attacker run as root- Any solution needs to work in the existing DaemonSet-to-DaemonSet deployment model with a shared hostPath volume
/kind feature
Summary
The driver communicates with provider plugins over unauthenticated Unix domain sockets in a shared hostPath directory. The provider_client.go explicitly notes that "the interface is only secured through filesystem ACLs."
This means any process on the node that can access the socket file can send Mount requests to the provider. While filesystem permissions and Pod Security Standards provide layers of defense, adding protocol-level authentication between the driver and provider would provide defense-in-depth.
Proposal
Add an authentication mechanism to the driver-provider gRPC communication so providers can verify the caller is the legitimate CSI driver. Possible approaches:
Context
Constraints
SO_PEERCRED(PID-based checks) is not viable because the driver and provider run in separate PID namespaces, causing the PID to resolve to 0SO_PEERCREDUID checks are also insufficient when both the driver and potential attacker run as root/kind feature