fc access control issue

fc access control issue

[Lv, Shuo]

Hi,
      When I use tcm_qla2xxx target, I found that the granularity for the FC access control  is very large and it is target-level. The LUNS in the target could be all accessed by initiator or the LUNS in the target could not be accessed by initiator. I don't know If the tcm_qla2xxx could create multiple targets for the same port? Could we implement the group level access  control? Like a group in a target could be access by a initiator, another group in the same target could be access by other initiator?   Any suggestion is welcome.

Regards
Shuo

Re: fc access control issue

[Nicholas A. Bellinger]

Hi Shuo,

On Tue, 2017-03-21 at 00:41 +0000, Lv, Shuo wrote:
> Hi,
>       When I use tcm_qla2xxx target, I found that the granularity for
> the FC access control  is very large and it is target-level. The LUNS
> in the target could be all accessed by initiator or the LUNS in the
> target could not be accessed by initiator. I don't know If the
> tcm_qla2xxx could create multiple targets for the same port?

Multiple targets per port is accomplished with a FC switch feature
called N_Port ID Virtualization (NPIV).

This allows multiple virtual WWPNs to be configured on a single physical
FC port, each with it's LIO target configfs namespace residing
under /sys/kernel/config/target/qla2xxx_npiv/$NPIV_WWPN/, et al.

Support for tcm_qla2xxx/NPIV was added in mainline v4.1 here:

https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg25618.html

and although information is pretty scarce how to actually use
tcm_qla2xxx/NPIV, there was some discussion back in 2015 about how it
currently works from an end-user perspective here:

https://lists.fedorahosted.org/pipermail/targetcli-fb-devel/2015-May/000157.html

> Could we implement the group level access  control? Like a group in a
> target could be access by a initiator, another group in the same
> target could be access by other initiator?   Any suggestion is
> welcome.
> 

I assume you mean a initiator access group abstraction, eg: where a
initiator group is associated with a specific target endpoint, and all
initiators associated with the group have ACLs added to the endpoint.

targetcli itself doesn't support initiator access groups, but there are
multiple vendors who have built initiator access group constructs into
their products atop python-rtslib, using vanilla LIO kernel code.

RE: fc access control issue

[Lv, Shuo]

Hi,  Bellinger: 
          Thanks for your detail explanation.
      Yes, I means initiator access group is like this. Similar to what you described. for example: LUNS in group A in a FC target could be access by a initiator A, LUNS in group B in a FC target could be access by a initiator B. LUNS in group A in a FC target could not be access by a initiator B. LUNS in group B in a FC target could not be access by a initiator B. the FC target is the same target.
    
    I think the initiator access groups could be implemented in the python-rtslib or LIO kernel code. Do you have any suggestion? Do you have plans to add this feature?

Regards
Shuo
-----Original Message-----
From: Nicholas A. Bellinger [mailto:nab@linux-iscsi.org] 
Sent: 2017年3月21日 15:03
To: Lv, Shuo
Cc: target-devel@vger.kernel.org; linux-rdma@vger.kernel.org
Subject: Re: fc access control issue

Hi Shuo,

On Tue, 2017-03-21 at 00:41 +0000, Lv, Shuo wrote:
> Hi,
>       When I use tcm_qla2xxx target, I found that the granularity for
> the FC access control  is very large and it is target-level. The LUNS
> in the target could be all accessed by initiator or the LUNS in the
> target could not be accessed by initiator. I don't know If the
> tcm_qla2xxx could create multiple targets for the same port?

Multiple targets per port is accomplished with a FC switch feature
called N_Port ID Virtualization (NPIV).

This allows multiple virtual WWPNs to be configured on a single physical
FC port, each with it's LIO target configfs namespace residing
under /sys/kernel/config/target/qla2xxx_npiv/$NPIV_WWPN/, et al.

Support for tcm_qla2xxx/NPIV was added in mainline v4.1 here:

https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg25618.html

and although information is pretty scarce how to actually use
tcm_qla2xxx/NPIV, there was some discussion back in 2015 about how it
currently works from an end-user perspective here:

https://lists.fedorahosted.org/pipermail/targetcli-fb-devel/2015-May/000157.html

> Could we implement the group level access  control? Like a group in a
> target could be access by a initiator, another group in the same
> target could be access by other initiator?   Any suggestion is
> welcome.
> 

I assume you mean a initiator access group abstraction, eg: where a
initiator group is associated with a specific target endpoint, and all
initiators associated with the group have ACLs added to the endpoint.

targetcli itself doesn't support initiator access groups, but there are
multiple vendors who have built initiator access group constructs into
their products atop python-rtslib, using vanilla LIO kernel code.

RE: fc access control issue

[Lv, Shuo]

Hi, In LIO FC target, has  the Access and devices visibility management (LUN masking) function been implemented? Access and devices visibility management allows for an initiator or
group of initiators to see different devices with different LUNs with necessary access permissions. If have not, do we have any plans?

Regards
Shuo

-----Original Message-----
From: Nicholas A. Bellinger [mailto:nab@linux-iscsi.org] 
Sent: 2017年3月21日 15:03
To: Lv, Shuo
Cc: target-devel@vger.kernel.org; linux-rdma@vger.kernel.org
Subject: Re: fc access control issue

Hi Shuo,

On Tue, 2017-03-21 at 00:41 +0000, Lv, Shuo wrote:
> Hi,
>       When I use tcm_qla2xxx target, I found that the granularity for 
> the FC access control  is very large and it is target-level. The LUNS 
> in the target could be all accessed by initiator or the LUNS in the 
> target could not be accessed by initiator. I don't know If the 
> tcm_qla2xxx could create multiple targets for the same port?

Multiple targets per port is accomplished with a FC switch feature called N_Port ID Virtualization (NPIV).

This allows multiple virtual WWPNs to be configured on a single physical FC port, each with it's LIO target configfs namespace residing under /sys/kernel/config/target/qla2xxx_npiv/$NPIV_WWPN/, et al.

Support for tcm_qla2xxx/NPIV was added in mainline v4.1 here:

https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg25618.html

and although information is pretty scarce how to actually use tcm_qla2xxx/NPIV, there was some discussion back in 2015 about how it currently works from an end-user perspective here:

https://lists.fedorahosted.org/pipermail/targetcli-fb-devel/2015-May/000157.html

> Could we implement the group level access  control? Like a group in a 
> target could be access by a initiator, another group in the same
> target could be access by other initiator?   Any suggestion is
> welcome.
> 

I assume you mean a initiator access group abstraction, eg: where a initiator group is associated with a specific target endpoint, and all initiators associated with the group have ACLs added to the endpoint.

targetcli itself doesn't support initiator access groups, but there are multiple vendors who have built initiator access group constructs into their products atop python-rtslib, using vanilla LIO kernel code.

Re: fc access control issue

[Nicholas A. Bellinger]

Hi Shuo,

On Sat, 2017-03-25 at 09:58 +0000, Lv, Shuo wrote:
> Hi, In LIO FC target, has  the Access and devices visibility
> management (LUN masking) function been implemented? Access and devices
> visibility management allows for an initiator or
> group of initiators to see different devices with different LUNs with
> necessary access permissions. If have not, do we have any plans?
> 

The NodeACLs + MappedLUNs logic as-is allow for different initiators to
see different LUN masking views on the same storage endpoint.

Eg, a single FC WWPN and it's default LUN layout under configfs
/sys/kernel/config/target/qla2xxx/$WWPN/$TPGT/lun/$LUN_ID/ can appear to
each $HOST_WWPN with any arbitrary mapping under
/sys/kernel/config/target/qla2xxx/$WWPN/$TPGT/acls/$HOST_WWPN/$LUN_ID/

RE: fc access control issue

[Lv, Shuo]

Thanks A. Bellinger.
     Which kernel version does it support NodeACLs + MappedLUNs logic function? How to configure this function? Any reference documents?

Regards
Shuo
-----Original Message-----
From: Nicholas A. Bellinger [mailto:nab@linux-iscsi.org] 
Sent: 2017年4月3日 5:38
To: Lv, Shuo
Cc: target-devel@vger.kernel.org; linux-rdma@vger.kernel.org
Subject: Re: fc access control issue

Hi Shuo,

On Sat, 2017-03-25 at 09:58 +0000, Lv, Shuo wrote:
> Hi, In LIO FC target, has  the Access and devices visibility 
> management (LUN masking) function been implemented? Access and devices 
> visibility management allows for an initiator or group of initiators 
> to see different devices with different LUNs with necessary access 
> permissions. If have not, do we have any plans?
> 

The NodeACLs + MappedLUNs logic as-is allow for different initiators to see different LUN masking views on the same storage endpoint.

Eg, a single FC WWPN and it's default LUN layout under configfs /sys/kernel/config/target/qla2xxx/$WWPN/$TPGT/lun/$LUN_ID/ can appear to each $HOST_WWPN with any arbitrary mapping under /sys/kernel/config/target/qla2xxx/$WWPN/$TPGT/acls/$HOST_WWPN/$LUN_ID/