Please, support inline (ephemeral) volumes or suggest an alternative approach for externally provisioned volumes

[Jan Hudec]

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

spec:
  volumes:
    - name: legacyappshare
      csi:
        driver: smb.csi.k8s.io
        volumeAttributes:
          source: //legacyapp.intranet.local/share
        nodePublishSecretRef:
          name: legacyapp-credentials

in the pod spec.

Describe alternatives you've considered

1. I can create a PV and PVC for that volume, but

   • 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.

2. 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.

3. 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.