CSI dynamic provisioning in a multitenancy model

Hi,

appreciate the interest in Unity. The short answer to your questions is that multi-tenancy support is achieved through K8s implementation design, ACLs and toolset. Multi-tenancy is beyond the scope of CSI drivers.

One might anticipate that implementing "proper" multi-tenancy tenant's networks will be isolated, hence iSCSI targets will be isolated as well.

Storage resources are going to be allocated via the storage classes that will be provisioned and provided to the tenant by the K8s admin. Dell EMC CSI Unit driver uses encrypted K8s tokens to securely access APIs. Tenants will have no modify rights to the storage class.

Hello, thanks very much for your reply.

I'm sorry to say that I couldn't find an answer to my question in your response, let me try another time.

My scenario has multiple independent clusters serving in a 1:1 model to different customers. The only thing they have in common is a connection to a MSP service network where we connect the iSCSI SAN (data and control plane).

When we provisión the storage we create:

1. A storage pool for each customer needs (where the volumes will be created dynamically) 
2. Api-rest credentials for each customer (as a way lo establish administrative domains)
3. Each customer's k8s cluster has a perimeter fw connected to the MSP service network that does nat to all internal initiated iscsi connections from the k8s nodes to the SAN. As a result each customer has a distinct IP that identified them against the SAN .

Doing so, and after deploying the CSI driver, what impedes a customer to execute an "iscsiadm discovery" from a pod or k8s node to visualize or mount a volume from other customers?.

In my view the only way is using whitelist IP filters and/or chap authentication at the SAN iscsi layer. If that's correct, can I include these attributes on the CSI settings without losing the dynamic provisioning feature?.

I hope it becomes clear enough.

Thanks for your help.

-David 

From the official pdf:

CSI Driver for Dell EMC Unity supports only FC protocol. Ensure that native multipath has
been installed on the nodes.
Note: PowerPath is not supported.

For Iscsi on Unity in general  , masking is used to ensure only relevant (registered) IQN is allowed access to the lun/ storage resource.

So if you're api interface can perform registration and masking , that would ensure basic security allowing that single host registered the required access.

Hello, thanks for your reply.

Bearing in mind that the IQN presented by the iscsi client is a string that anybody with access to the host can change I don't see on it a hard solution to limit access between customers.

https://www.server-world.info/en/note?os=Ubuntu_18.04&p=iscsi&f=3

Regards,

-David 

Just to close on this, we are looking to add CHAP support in the upcoming CSI for Unity release. 

As for your specific requirements regarding chap authentication and multitenancy features, here's the information you need:

1. CHAP Authentication: The Unity 380F does support CHAP (Challenge-Handshake Authentication Protocol) authentication. CHAP is a security feature used in iSCSI (Internet Small Computer System Interface) to authenticate the identity of initiators (clients) and targets (storage systems). By enabling CHAP authentication, you can ensure secure communication between the storage array and the iSCSI clients.

2. Multitenancy: The concept of multitenancy refers to the ability to host multiple isolated instances of an application or service, serving different customers or tenants, on a shared infrastructure. However, Unity storage systems do not have native multitenancy features built-in. Unity arrays are typically used within a single tenant or organization, and the system itself does not provide explicit mechanisms for isolating customer data or controlling access between tenants.

To achieve multitenancy-like functionality in your scenario, you may need to implement additional measures outside of the Unity 380F system itself. For example, you can leverage networking and security infrastructure to isolate customer traffic and enforce access controls. This can be done through virtual LANs (VLANs), access control lists (ACLs), and other network segregation techniques.

It's important to note that while Unity 380F offers robust data management and security features, it may not inherently provide  all the specific multitenancy capabilities you require. It would be advisable to consult with Dell EMC or a technical expert to discuss your specific use case and explore potential solutions or alternatives that align with your requirements.

Remember to conduct thorough research and engage with the product vendor or experts to ensure that the Unity 380F meets your precise needs for secure data sharing and multitenancy.