Security and Multi-Tenancy Concerns

[RakutenStorage]

Hi Team, In our Kubernetes (K8s) environment, each application team is assigned their own namespace, and they deploy their own pods within it. While testing the NetApp Trident integration, we observed the following and would appreciate your feedback on how we can address these concerns:

1. Tenant A provisions a PersistentVolumeClaim (PVC) named pvc1.
2. How does the system ensure that Tenant B cannot access pvc1 or its underlying PersistentVolume (PV)?
3. What security mechanisms are in place (e.g., namespace isolation, RBAC, storage-level encryption, etc.) to enforce tenant isolation and prevent unauthorized access?
4. Are there any best practices to enhance security in a multi-tenant Kubernetes environment using NetApp Trident?

In our current setup, PVCs are namespace-scoped, and each application team has access only to their respective namespace. Looking forward to your input.
Thanks

[chamfer]

Hi @RakutenStorage,

Referencing the below diagram and the URL here Architecture which depicts ONTAP w/ Trident w/ OpenShift (understanding there are differences to standard K8s).

Q2: How does the system ensure that Tenant B cannot access pvc1 or its underlying PersistentVolume (PV)?

A2: SVM isolation between tenants

Q3: What security mechanisms are in place (e.g., namespace isolation, RBAC, storage-level encryption, etc.) to enforce tenant isolation and prevent unauthorized access?

A3: SVM isolation and K8s Kubernetes Storage Resource Quotas.  You could have SVMs on different aggregates with aggregate encryption keys.    Per volume encryption via NVE is supported with Trident.

Note:

• If NAE (NetApp Aggregate Encryption) is enabled on the backend, any volume provisioned in Trident will be NAE-enabled.

  • You can set the NVE encryption flag to "" to create NAE-enabled volumes.

• If NAE is not enabled on the backend, any volume provisioned in Trident will be NVE-enabled (NetApp Volume Encryption) unless the NVE encryption flag is set to false (the default value) in the backend configuration.

• Reference Security

Q4: Are there any best practices to enhance security in a multi-tenant Kubernetes environment using NetApp Trident?

A4: Yes, refer to here Security

[RakutenStorage]

Hi Chamfer
In our environment, we have a Kubernetes (K8s) cluster that is used by different application teams. Each application team has a Namespace administrator. On the NetApp side, we cannot create multiple SVMs for each application team.
Hence, the above approach will not be applicable to us.

[LuisRico]

Hi @RakutenStorage , 

The security isolation that you are asking (2) is provided by Kubernetes directly using namespaces. Tenant-A has access only to namespace A, and can only use PVCs created in the namespace A. PVCs are namespace-scoped in Kubernetes in general, not only in your current setup. This namespace isolation (3) is the multi-tenant capability provided by Kubernetes, if you are using Kubernetes RBAC and each "application team" or tenant A or B has access only to their namespace A or B. That will work with Trident or any other storage provisioner. 

In addition to that, you can use ONTAP-level encryption, and also client-side encryption with Trident using LUKS for iSCSI and NVMe/TCP backends.

Outside of Kubernetes, Trident makes sure that only the worker nodes authorized to mount the PVs are the ones able to do it, with export policies for NFS, restricting IP addresses of worker nodes authorized to mount volumes. For other protocols, we have similar security measures with IQNs for iSCSI, NQN for NVMe namespaces or WWPN for FC protocol. 

Hope this helps to clarify. 

Thanks. Regards.