implement Ephemeral Inline Volumes support

[andyzhangx]

Is your feature request related to a problem?/Why is this needed

Describe the solution you'd like in detail

refer to
https://kubernetes-csi.github.io/docs/ephemeral-local-volumes.html#which-feature-should-my-driver-support

Describe alternatives you've considered

Additional context

[boddumanohar]

Generic ephemeral volumes feature was alpha in Kubernetes 1.19. A CSI driver is suitable for generic ephemeral inline volumes if it supports dynamic provisioning of volumes. It creates PVCs underneath so any CSI driver that supports PVCs will work without any special support. As dynamic volume provisioning feature is already there in csi-driver-nfs, I think we already have support for this.

more info: https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes

[boddumanohar]

should we rename this issue to implement Generic ephemeral volumes support?

[kfox1111]

@boddumanohar that is a different feature. That is the ability to ask for temporary volumes with no details.

inline ephemeral is needed to replace the built in functionality to directly mount an nfs volume by server:/path specified in the pod spec without making a pv

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[kfox1111]

/remove-lifecycle rotten

[kfox1111]

Still valid.

[jsafrane]

Why is this valid? The linked document says:

A CSI driver is not suitable for CSI ephemeral inline volumes when:

• provisioning is not local to the node
• ephemeral volume creation requires volumeAttributes that should be restricted to an administrator, for example parameters that are otherwise set in a StorageClass or PV. Ephemeral inline volumes allow these attributes to be set directly in the Pod spec, and so are not restricted to an admin.

There is no storage class, so the only option is to pass NFS server name + base path via VolumeAttributes. That could allow anyone who can write a pod to access any NFS server reachable to a node. That does not sound right.

I don't think a generic NFS driver should implement in-line ephemeral volumes. Users should use Generic Ephemeral Inline Volumes and the driver "implements" that already (for the driver it's just a generic PVC + dynamically provisioned PV).

[kfox1111]

There are sites out there that have existing NFS volumes, that are currently being used with the existing pod spec like:

spec:
  volumes:
    - name: nfs-volume
      nfs: 
        # URL for the NFS server
        server: 10.108.211.244
        path: /

Yes, this functionality can be a security issue, but when tied in with a policy by PSP, OPA Gatekeeper, or Kyverno, it can be safe for those allowed to use it. If the nfs csi driver is to fully take over from what the current podspec supports, it will need to support this access mode.