Add documentation notes about mounting existing volumes

[displague]

The readme does not include instructions on mounting existing volumes.

The Kubernetes Blog included some very helpful documentation on this, which can be adapted for use in the docs of this project:

https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/#pre-provisioned-volumes

[LuminousPath]

just as an inquiry, I think mounting an existing volume would look something like this:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-persistentvolume
  annotations:
    pv.kubernetes.io/provisioned-by: linodebs.csi.linode.com
spec:
  storageClassName: linode-block-storage-retain
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  claimRef:
    namespace: default
    name: my-persistentvolumeclaim
  csi:
    driver: linodebs.csi.linode.com
    volumeHandle: <linode_volume_label>
    readOnly: false
    fsType: ext4
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-persistentvolumeclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: linode-block-storage-retain
  volumeName: my-persistentvolume

I put the volumeName and claimRef to lock the pvc to the volume. This doesn't seem to work, however, so I'm guessing I'm missing something vital in the PersistentVolume

[displague]

An example of how to mount an existing volume is available here: https://www.linode.com/community/questions/20185/mounting-an-existing-volume-to-lke#answer-74789

@LuminousPath's yaml looks correct, the <linode_volume_label> should be {ID}-{Label}. You can find the ID and Label with the linode-cli.

[displague]

I tried repeating the steps in the community post and ran into 403s as others have experienced. I believe this volume was created by the same cluster, but can't confirm.

I doubt the reason given, that LKE Linode API access tokens do not have access to block storage volumes created outside of the cluster.

If so, this would limit the ability for users to migrate storage between clusters along with various disaster recovery scenarios. This also reduces the benefits of CSI cloning.

I'm curious if the 403s are coming from a Kubermetes API or the RPC between CSI services.

I intend to use Linode CLI to verify whether the LKE token (available in a cluster secret) does or does not have access to mount a volume to a cluster node.

[displague]

Ok. I've confirmed that the LKE API token used by the Linode service account used by CSI has access to volumes it created but does not have permission to the volumes that I'd like to access from previous LKE environments:

export LINODE_CLI_TOKEN=$(kubectl get secrets -n kube-system linode -o template='{{.data.token | base64decode}}') 
linode profile view # username=lke-service-account-{redacted} email:null restricted:true
linode volumes list

Further, linode-cli does not offer a linode users grants action (this is explicitly denoted to be skipped in the OpenAPI spec for Linode CLI). Even if you attempt to add the volume access grants as an account owner, by hand, you can't. Service accounts in this context are service-controlled, not user-controlled.

$ curl -H "Content-Type: application/json" \
                -H "Authorization: Bearer $TOKEN" \
                -X GET \
                https://api.linode.com/v4/account/users/$USERNAME/grants
{"errors": [{"reason": "Not found"}]}

[displague]

Modest Linode API feature request time? Give users the ability to extend grants, if only for storage?

Alternatively, use separate tokens for LKE services and allow users to modify the CSI token to one that they can manage? To some extent this may already be permitted, however, it may be reset on LKE upgrades. or other lifecycle reconciliation refreshes. Perhaps LKE could be made to respect a user-supplied CSI token? (get this from an annotation? an LKE cluster grants option?)

[displague]

Perhaps something that could be done within linode-blockstorage-csi-driver is to honor StorageClass parameters to override the secretnamespace and secretname: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims

https://kubernetes.io/docs/concepts/storage/storage-classes/#parameters

This would allow users to create a new StorageClass with alternate grants sufficient to manage linode block storage volumes creates by region adjacent LKE clusters and non-LKE workloads.