You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem?/Why is this needed
I have a Kubernetes application that needs to access a SMB3 share exposed by non-Kubernetes server.
In the past I used the flexVolume driver juliohm/cifs, specified directly in the pod spec of the deployment. But that driver has disappeared and cannot be easily installed any more. So I am looking to replace it with a CSI one.
Unfortunately inline volume is not supported, and creating a PV for this feels wrong, because the PV is not managed by the cluster. Instead, it is specific set of mount parameters to be used by that app and that app only.
I have to be careful not to damage the content with the lifecycle hooks. I do not want to clean it up either on provisioning or release, it is provisioned externally.
It feels wrong to have non-namespaced PV for something that is inherently specific to the application.
I can make the pod privileged and simply run a
mount -t cifs //legacyapp.intranet.local/share /mnt/legacyapp -odomain=d,username=$USER,password=$PASSWORD
inside.
I could even modify the application to use a userland CIFS/SMB3 library.
Additional context
I've seen some talk about this being not implemented for NFS for security reasons, but because of the last option I don't believe there actually are security reasons here. The application operator can access the share anyway if they have the credentials, and mounting it doesn't eat more resources than accessing it in some other way.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem?/Why is this needed
I have a Kubernetes application that needs to access a SMB3 share exposed by non-Kubernetes server.
In the past I used the flexVolume driver
juliohm/cifs
, specified directly in the pod spec of the deployment. But that driver has disappeared and cannot be easily installed any more. So I am looking to replace it with a CSI one.Unfortunately inline volume is not supported, and creating a PV for this feels wrong, because the PV is not managed by the cluster. Instead, it is specific set of mount parameters to be used by that app and that app only.
Describe the solution you'd like in detail
in the pod spec.
Describe alternatives you've considered
I can create a PV and PVC for that volume, but
I can make the pod privileged and simply run a
inside.
I could even modify the application to use a userland CIFS/SMB3 library.
Additional context
I've seen some talk about this being not implemented for NFS for security reasons, but because of the last option I don't believe there actually are security reasons here. The application operator can access the share anyway if they have the credentials, and mounting it doesn't eat more resources than accessing it in some other way.
The text was updated successfully, but these errors were encountered: