- 
                Notifications
    
You must be signed in to change notification settings  - Fork 364
 
Description
What happened:
csi-endpoint flag is advertised to accept any gRPC endpoint:
--csi-address string The gRPC endpoint for Target CSI Volume. (default "/run/csi/socket")
but on practice it is strongly bound to unix sockets, forbidding the case to run external provisioner separately.
What you expected to happen:
Accept TCP gRPC and communicate with it the same way it does today through unix sockets.
How to reproduce it:
Pass any grpc endpoint (or any string that does not start with unix:// into csi-endpoint flag.
csi-provisioner.go:229] OnConnectionLoss callback only supported for unix:// addresses
Anything else we need to know?:
In order to simplify the multi-tenancy orchestration and efficiency it would be great to have CSI controller that could handle multiple tenants. The only blocking part now, that csi-provisioner (as well as csi-attacher, resizer, e.t.c) are explicitly setting connection.OnConnectionLoss(connection.ExitOnConnectionLoss()) params that are restricted to unix sockets only: https://github.com/kubernetes-csi/csi-lib-utils/blob/master/connection/connection.go#L231
Is there any reason for such restriction or just overlook?
I also noticed gRPC client connection is established insecure, which also prevents it to be trusted enough.
Environment:
- Driver version: v5.2.0
 - Kubernetes version (use 
kubectl version): v1.33