Opened github issues:
Removing host from access control list does not close NVMeF connections -
https://github.com/spdk/spdk/issues/577
nvme discover shows all target subsystems, even those that are not accessible by the host
-
https://github.com/spdk/spdk/issues/576
________________________________
From: SPDK <spdk-bounces(a)lists.01.org> on behalf of Walker, Benjamin
<benjamin.walker(a)intel.com>
Sent: Thursday, January 10, 2019 9:56 AM
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 Shahar Salzman
Sent: Wednesday, January 9, 2019 3:45 PM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Cc: Eyal Shnitzer <eyal.shnitzer(a)kaminario.com>
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?
I consider these bugs, so filing GitHub issues would be the best way to track them.
Thanks!
________________________________
From: SPDK <spdk-bounces(a)lists.01.org> on behalf of Walker, Benjamin
<benjamin.walker(a)intel.com>
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>
> Cc: Eyal Shnitzer <eyal.shnitzer(a)kaminario.com>
> 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>
> Cc: Eyal Shnitzer <eyal.shnitzer(a)kaminario.com>
> 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
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk