Unsolved

1 Rookie

 • 

3 Posts

 • 

2 Points

153

January 30th, 2026 17:14

PowerMax CSI Driver scenario query regarding Isolation Mechanism

Current example setup details as follows.

Unisphere Endpoint: 
    • For Site-1 - Dev/ Test/ PROD Unisphere Endpoint = https://xx.xx.xx.xx:8443
    • For Site-2 - Dev/ Test/ PROD Unisphere Endpoint = https://xx.xx.xx.xx:8443
    • A single Unisphere endpoint is used for Dev, Test, and Prod on each sites above.

User Account Scope:
    • A single Unisphere user account (test-admin) with full admin PowerMax array access is used.
    • This account has visibility and control across Dev, Test, and Prod storage.
    • There are no dedicated Unisphere users per environment.

CSI Driver Deployment:
    • Each environment (Dev, Test, Prod) runs on its own Kubernetes cluster.
        o Dev → Dev_Cluster
        o Test → Test_Cluster
        o Prod → Prod_Cluster
• Each cluster would have its own CSI driver deployment, which is good practice.

Are my key observations on isolation of the CSI driver capability among the environments correct?

1. Primary Isolation Mechanism Today
    • Isolation is currently enforced only through Port Groups.
    • While this is valid, it relies heavily on correct CSI configuration.
2. Unisphere User Privilege
    • Since the same Unisphere user has full array access, any misconfiguration in CSI (intentional or accidental) could allow:
        o Dev workloads to attach to Test or Prod Port Groups.
     • There is no RBAC guardrail at the native Unisphere level today.

Are there any possibilities for isolation from one env to another while provisioning PV/PVC

2 Intern

 • 

14 Posts

 • 

9 Points

February 10th, 2026 00:08

Few things:
1) with NVMeTCP and iSCSI, you specify the port groups for the servers to use, but not with FC
2) servers from the same cluster can connect to the PowerMax through different port groups, and for large clusters this is encouraged.
3) is this an operator or helm based deployment?
    You will need to have a specific 3 character CLUSTER_PREFIX for each cluster using the CSI driver so there are no naming colisions, and so you can find your resources easily (storage team would be able to distinguish storage groups, hosts, masking views, etc)
        # X_CSI_K8S_CLUSTER_PREFIX: Define a prefix that is appended onto
        # all resources created in the Array
        # This should be unique per K8s/CSI deployment
        # maximum length of this value is 3 characters
        # Default value: "CSM"
        # Examples: "XYZ", "EMC"
        - name: X_CSI_K8S_CLUSTER_PREFIX
          value: "CSM"
4) You can have different credentials used for each CSM / CSI driver deployment (per cluster)
5) no, with these best practices, you will not have volumes being attached to the wrong hosts/clusters; Its not just the port groups that provide isolation;  its the host presentation.  and K8s and the Dell CSI driver knows exactly which volume on the storage array is associated with each created PV.
6) There are options for more isolation if needed, if you would like to reach out to me directly - dan.cohen@dell.com

1 Rookie

 • 

1 Message

 • 

2 Points

March 19th, 2026 13:06

@bspintu88e016 Can you please confirm if this resolved your issue? Thanks!

1 Rookie

 • 

3 Posts

 • 

2 Points

March 20th, 2026 00:43

Thank you Dan for your valuable inputs.

1 Rookie

 • 

3 Posts

 • 

2 Points

March 20th, 2026 00:43

@ramams8​ - Yes got clarity.

No Events found!

Top