#Shared SVM for multiple cluster and PVC separation.

1 messages · Page 1 of 1 (latest)

hidden forge
#

Hello, I'm a bit of a newbie and I setup a NFS svm on a FAS8300 for usage with trident. I would like to use a single SVM to store PVC's from multiple dedicated k8s clusters as well as for two a large shared k8s cluster.

I intend to use prefix for my volumes to identify volume/cluster/customer, where I am confused is how to ensure customer in namespace A cannot temper with NFS PVC of customer in namespace B and vice versa.

Is this isolated by design ?

rough zealot
#

if your user/customer has access to the backend config, I'm pretty sure he can change it and access the data of the other customer(s). You have no isolation on a network level either, so if he "guesses" the IP range of your other customer, he can manually mount the datastores too.
For separate customers it's best to use ipspaces and separate SVMs

hidden forge
#

Hi Darkstar, thanks, yeah good point...

There is only 1 trident backend config per clusters apparently and indeed, If a customer has cluster admin privilege then he can temper with the trident backend. That's actually the case in one of of the dedicated cluster for business reason the customer has cluster admin...

In case the customers are "jailed" in their namespace and only have access to the storage class, I am thinking this might work securely or am I seeing it wrong? Also This page seems to suggest that a PVC created in a namespace cannot be used in another namespace https://docs.netapp.com/us-en/trident/trident-reco/deploy-reco.html

There's also this https://netapp-trident.readthedocs.io/en/stable-v20.07/kubernetes/operations/tasks/backends/ontap/ontap-nas/dynamic-export-policies.html
I don't fully understand but I think maybe I can use dyn. export policies to specify which customer subnet can reach which volumes. But I might understand it wrong

Also got to read about Getekeeper, I'm tinking this could also help but it's quite complex/confusing https://github.com/open-policy-agent/gatekeeper-library/tree/master/library/pod-security-policy/volumes

rough zealot
#

I'm not deep enough into k8s knowledge that I can confidently answer your questions, but I believe at least for your first question, the answer is "yes", i.e. if you somehow prevent the customer access to the backend config (and only provide access to the StorageClass), then it should be safe. But to be really sure you need to make sure that the customer does not have SSH/admin access to the etcd nodes as well, otherwise I guess they could tamper with the etcd database directly? Not sure...

viscid shadow
#

You said "There is only 1 trident backend config per clusters". This is not a Trident limitation, so you can't count on Trident enforcing that.

hidden forge
#

Hi @valid mountain that's right, I was mistaken, apparently we can have multiple trident backend config per cluster.