-----Original Message----- From: SPDK [mailto:spdk-bounces@lists.01.org] On Behalf Of Howell, Seth Sent: Monday, January 7, 2019 6:36 PM To: Storage Performance Development Kit <spdk(a)lists.01.org&gt; Cc: Eyal Shnitzer <eyal.shnitzer(a)kaminario.com&gt; Subject: Re: [SPDK] Access control on the subsystem NQN Hi Shahar, These are great questions! The first one I am just answering intuitively, I think that if a host is removed from from the subsystem whitelist, all of its connections should be dropped. I can't think of an instance where we would want an unauthorized host to maintain access to storage resources for an arbitrary amount of time. In regards to the second question, I found the following from the spec: "NVMe over Fabrics defines a discovery mechanism that a host uses to determine the NVM subsystems that expose namespaces that the host may access. The discovery Service provides a host with the following capabilities: The ability to discover a list of NVM subsystems with namespaces that are accessible to the host; . . . " This quote makes it sound to me that if a host is not allowed to access a namespace, that namespace should not be returned to that host when it makes a discovery request. I will defer to Ben if he wants to shoot me down on this, but I think that if you want to close all of the connections between a subsystem and a host is removed from its ACL, and change the way the discovery service works.

Something to think about is that we are planning to add (NVMe in-band) authentication support in 19.04. I am in the early stages of investigating this, but it seems that authentication and the subsystem host access lists are complimentary and the implementation of one should not directly affect the other. Theoretically could use any combination of providing whitelists of hosts to each subsystem, and allowing any host to connect to a subsystem but requiring authentication before submitting any I/O or admin requests. Thanks, Seth -----Original Message----- From: SPDK [mailto:spdk-bounces@lists.01.org] On Behalf Of Shahar Salzman Sent: Monday, December 31, 2018 8:14 AM To: Storage Performance Development Kit <spdk(a)lists.01.org&gt; Cc: Eyal Shnitzer <eyal.shnitzer(a)kaminario.com&gt; Subject: [SPDK] Access control on the subsystem NQN Hi, On a previous thread, I got the great answer that a subsystem is actually an access control list. We have been using it as such, but some of the behavior seems odd. On host_remove the sessions to the hosts are not disconnected, this means that even though I removed the host from the ACL, it will have access, until it disconnects (although it cannot connect another session). In addition, a host can see all the subsystems exposed on the IP, even though it has access to only some of them. We would be happy to work on these issues, but I would like to understand the expected behavior. Thanks, Shahar _______________________________________________ SPDK mailing list SPDK(a)lists.01.org https://lists.01.org/mailman/listinfo/spdk _______________________________________________ SPDK mailing list SPDK(a)lists.01.org https://lists.01.org/mailman/listinfo/spdk

-----Original Message----- From: SPDK [mailto:spdk-bounces@lists.01.org] On Behalf Of Shahar Salzman Sent: Wednesday, January 9, 2019 3:45 PM To: Storage Performance Development Kit <spdk(a)lists.01.org&gt; Cc: Eyal Shnitzer <eyal.shnitzer(a)kaminario.com&gt; Subject: Re: [SPDK] Access control on the subsystem NQN Great to hear this. Not sure when we will get to working on these issues, but we will definitely put some work into them. I believe that removing the connection on ns_remove takes priority between the two issues. We will update when we start working on it. Should this go into trello as a task? Or should I open bugs on github?

________________________________ From: SPDK <spdk-bounces(a)lists.01.org&gt; on behalf of Walker, Benjamin <benjamin.walker(a)intel.com&gt; Sent: Tuesday, January 8, 2019 5:06 PM To: Storage Performance Development Kit Cc: Eyal Shnitzer Subject: Re: [SPDK] Access control on the subsystem NQN > -----Original Message----- > From: SPDK [mailto:spdk-bounces@lists.01.org] On Behalf Of Howell, > Seth > Sent: Monday, January 7, 2019 6:36 PM > To: Storage Performance Development Kit <spdk(a)lists.01.org&gt; > Cc: Eyal Shnitzer <eyal.shnitzer(a)kaminario.com&gt; > Subject: Re: [SPDK] Access control on the subsystem NQN > > Hi Shahar, > > These are great questions! > > The first one I am just answering intuitively, I think that if a host > is removed from from the subsystem whitelist, all of its connections > should be dropped. I can't think of an instance where we would want an > unauthorized host to maintain access to storage resources for an arbitrary amount of time. > > In regards to the second question, I found the following from the spec: > "NVMe over Fabrics defines a discovery mechanism that a host uses to > determine the NVM subsystems that expose namespaces that the host may > access. The discovery Service provides a host with the following capabilities: > The ability to discover a list of NVM subsystems with namespaces that > are accessible to the host; . . . " > This quote makes it sound to me that if a host is not allowed to > access a namespace, that namespace should not be returned to that host > when it makes a discovery request. > I will defer to Ben if he wants to shoot me down on this, but I think > that if you want to close all of the connections between a subsystem > and a host is removed from its ACL, and change the way the discovery service works. I concur. These are both bugs - the connections should drop and the subsystem should not show up in the discovery log if the host does not have access/loses access to the subsystem. > > Something to think about is that we are planning to add (NVMe in-band) > authentication support in 19.04. I am in the early stages of > investigating this, but it seems that authentication and the subsystem > host access lists are complimentary and the implementation of one > should not directly affect the other. Theoretically could use any > combination of providing whitelists of hosts to each subsystem, and > allowing any host to connect to a subsystem but requiring authentication before submitting any I/O or admin requests. > > Thanks, > > Seth > > > > > -----Original Message----- > From: SPDK [mailto:spdk-bounces@lists.01.org] On Behalf Of Shahar > Salzman > Sent: Monday, December 31, 2018 8:14 AM > To: Storage Performance Development Kit <spdk(a)lists.01.org&gt; > Cc: Eyal Shnitzer <eyal.shnitzer(a)kaminario.com&gt; > Subject: [SPDK] Access control on the subsystem NQN > > Hi, > > On a previous thread, I got the great answer that a subsystem is > actually an access control list. > We have been using it as such, but some of the behavior seems odd. > > On host_remove the sessions to the hosts are not disconnected, this > means that even though I removed the host from the ACL, it will have > access, until it disconnects (although it cannot connect another session). > In addition, a host can see all the subsystems exposed on the IP, even > though it has access to only some of them. > > We would be happy to work on these issues, but I would like to > understand the expected behavior. > > Thanks, > Shahar > _______________________________________________ > SPDK mailing list > SPDK(a)lists.01.org > https://lists.01.org/mailman/listinfo/spdk > _______________________________________________ > SPDK mailing list > SPDK(a)lists.01.org > https://lists.01.org/mailman/listinfo/spdk _______________________________________________ SPDK mailing list SPDK(a)lists.01.org https://lists.01.org/mailman/listinfo/spdk _______________________________________________ SPDK mailing list SPDK(a)lists.01.org https://lists.01.org/mailman/listinfo/spdk