[SPDK] Access control on the subsystem NQN

[SPDK] Access control on the subsystem NQN

[Shahar Salzman]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

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

Re: [SPDK] Access control on the subsystem NQN

[Shahar Salzman]

[-- Attachment #1: Type: text/plain, Size: 5833 bytes --]

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(a)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(a)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(a)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

Re: [SPDK] Access control on the subsystem NQN

[Walker, Benjamin]

[-- Attachment #1: Type: text/plain, Size: 5139 bytes --]

> -----Original Message-----
> From: SPDK [mailto:spdk-bounces(a)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(a)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(a)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

Re: [SPDK] Access control on the subsystem NQN

[Shahar Salzman]

[-- Attachment #1: Type: text/plain, Size: 4329 bytes --]

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> 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(a)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(a)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

Re: [SPDK] Access control on the subsystem NQN

[Walker, Benjamin]

[-- Attachment #1: Type: text/plain, Size: 3578 bytes --]



> -----Original Message-----
> From: SPDK [mailto:spdk-bounces(a)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(a)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

Re: [SPDK] Access control on the subsystem NQN

[Howell, Seth]

[-- Attachment #1: Type: text/plain, Size: 2768 bytes --]

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(a)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