Open Stack

Bug/RFE is up!

https://bugs.launchpad.net/neutron/+bug/1669630

Hopefully that sums of what I'm ideally after well enough, and is useful
to the greater community and project as a whole.

Cheers,
Adrian Turjak

On 01/03/17 22:00, Adrian Turjak wrote:
> Hello Kevin,
>
> Thanks for the prompt response! This is fantastic. I'll throw up a
> blueprint together tomorrow.
>
> Backwards compatibility is the biggest issue, as anyone currently
> using the feature and assuming no approval step is going to be hit by
> it. The only sensible solution I can see being easy to accomplish is
> to make the change as a config setting that a deployer has to turn on.
> Then should someone want the approval step, they can issue a
> deprecation warning and eventually make the switch. Private clouds
> likely wouldn't turn the acceptance workflow on but for public clouds
> like us it would work. 
>
> Also for deployers yet to expose the feature, they can make the change
> as they open the policy for the service.
>
> Trying to fit both versions (no acceptance, required acceptance)
> together would be a mess. Best to just offer the option as which is
> wanted to the deployer and avoid the pain of trying to safely and
> securely do both when they conflict.
>
> The ability to limit it to the same project tree or a project you have
> roles in would be nice, but I fully agree that trying to introduce a
> connection here to Keystone could be a pain. If made as a another
> configuration option it could work possibly. Neutron already has a
> keystone admin user, and doing the required calls to keystone here
> wouldn't be too hard. Checking for the same tree is an easy upwards
> traversal, once root is reached, compare root for both projects, sadly
> more than one API call, but not too bad. User role checking is easy,
> and just a single call to the role assignments API. As for rechecking,
> I wouldn't bother. Projects can't be reparented, and while user roles
> can change it is mostly safe to assume that this network sharing was
> safe due to them having a role originally. No polling needed. My idea
> here was to do the checks, and if neither was true, then require
> acceptance.
>
> At any rate, even just an acceptance workflow would solve my core
> problem, but I'll write up the proposal for the full plan, and we can
> redesign from there!
>
> Regards,
> Adrian Turjak
>
>
> On 1/03/2017 9:27 PM, Kevin Benton <kevin at benton.pub> wrote:
>
>     Hi Adrian,
>
>     Thanks for the write-up.
>
>     I think adding an approval workflow to Neutron is a reasonable
>     feature request. It probably wouldn't be back-portable because
>     it's going to require an API change and a new column in the
>     database for approval state so you would have to patch it in
>     manually in your cloud (assuming you don't want to wait for Pike).
>
>     The tricky part is going to be figuring out how to handle API
>     backward compatibility. Requiring an extra step before a project
>     is allowed to use a network shared to it would break existing
>     automation that depends on the current workflow. 
>
>
>     Please file an request for enhancement against Neutron[1] and we
>     can continue the discussion of how to implement this on the bug
>     report.
>
>
>     As for your option 2, the reason Neutron can't do something like
>     that automatically right now is due to a lack of strong Keystone
>     integration. Outside of the middleware that authenticates
>     requests, Neutron doesn't even know keystone exists. We have no
>     way to prevent changes on the keystone side that would violate the
>     current RBAC policies (e.g. a user is using a network that they
>     wouldn't be able to use after a keystone modification). We also
>     have no framework in place to even see keystone alterations when
>     they happen so it would require constant background polling.
>
>
>     1. https://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
>
>
>     Cheers,
>     Kevin Benton
>
>     On Tue, Feb 28, 2017 at 7:43 PM, Adrian Turjak
>     <adriant at catalyst.net.nz <mailto:adriant at catalyst.net.nz>> wrote:
>
>         Hello Openstack-Devs,
>
>         I'm just trying to find out if there is any proposed work to
>         make the
>         network RBAC a bit safer.
>
>         For context, I'm part of a company running a public cloud and
>         we would
>         like to expose Network RBAC to customers who have multiple
>         projects so
>         that they can share networks between them. The problem is that the
>         network RBAC policy is too limited.
>
>         If you know the project id, you can share a network to that
>         project id.
>         This allows you to name a network 'public' or 'default' and
>         share it to
>         others in hopes of them connecting to it where you then
>         potentially
>         compromise their instances. Effectively this allows honey-pot
>         networks.
>         The only layer of safely you have is first needing to gleam a
>         project id
>         before you can do this, effectively security through
>         obscurity, which is
>         a terrible approach.
>
>         Ideally network RBAC should work the same as image sharing in
>         Glance.
>         You share a network, and the other project must accept it
>         before it
>         becomes usable. This doesn't stop a too trusting party from
>         accepting an
>         unsafe network, but it means they have some warning before doing
>         anything silly. Otherwise the onus is on them to always be
>         vigilant for
>         shared networks that shouldn't be there, which is not exactly
>         something
>         we want our customers to have to worry about.
>
>         Are there plans to implement some sort of acceptance process
>         for network
>         RBAC in Neutron, or a willingness to? Other options are to
>         only allow
>         sharing to projects you have a role in, or projects in same
>         hierarchical
>         'tree'. If I throw up a spec/blueprint for this is there
>         interest in
>         following through with dev work, or would there be support if
>         I or other
>         members of our company decide to help implement such a change?
>
>         If not, I've considered a few options I can do around this,
>         and I'd be
>         curious on people's thoughts:
>         1. Expose Network RBAC as is and setup automated auditing to
>         check for
>         shared networks policies outside of their hierarchical tree,
>         or between
>         projects that don't have shared users.
>         2. Build into our workflow service a new plugin to expose a
>         neutron
>         RBAC-like API which in the background uses the Neutron API
>         with an admin
>         account on your behalf. This service would enforce a level of
>         custom
>         policy that we'd want before allowing the creation of a
>         network RBAC
>         policy. That way networks can only be shared between projects
>         in the
>         same tree, or if the requesting user has roles in both
>         projects. If
>         anyone attempts to share beyond that scope, we will require an
>         admin to
>         approve the request before the network is shared, or simply
>         deny it.
>         Think of this as a wrapper/proxy around Network RBAC to allow
>         stronger/flexible policy. In this scenario the Neutron policy
>         would
>         limit RBAC to admin only.
>
>         Option 1 is easy, but reactive, which in larger deployments,
>         or with
>         larger customer bases isn't great since parsing that much data
>         as a
>         human is hard, and writing the auditing to tell us what is
>         'unsafe'
>         correctly isn't easy. We may not always catch things fast
>         enough, or
>         we'll catch too much and have to process it.
>         Option 2 is a bit more work, and means clients have to
>         interact with a
>         different API instead (which we'd document to our customers
>         and provide
>         a horizon panel for it), but gives us as deployers far more
>         safety and
>         security.
>
>         So, what to do? Is it worth trying to make this feature safer in
>         Neutron? Will we get the support to make it happen? Or should
>         we just
>         develop something around it so it works for us as we need it
>         to? It's a
>         very useful feature, but as it stands it's too unsafe to
>         expose in a
>         public cloud environment.
>
>         Regards,
>         Adrian Turjak
>
>
>
>
>
>         __________________________________________________________________________
>         OpenStack Development Mailing List (not for usage questions)
>         Unsubscribe:
>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>         <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
>
> Hello Kevin,
>
> Thanks for the prompt response! This is fantastic. I'll throw up a blueprint together tomorrow.
>
> Backwards compatibility is the biggest issue, as anyone currently using the feature and assuming no approval step is going to be hit by it. The only sensible solution I can see being easy to accomplish is to make the change as a config setting that a deployer has to turn on. Then should someone want the approval step, they can issue a deprecation warning and eventually make the switch. Private clouds likely wouldn't turn the acceptance workflow on but for public clouds like us it would work. 
>
> Also for deployers yet to expose the feature, they can make the change as they open the policy for the service.
>
> Trying to fit both versions (no acceptance, required acceptance) together would be a mess. Best to just offer the option as which is wanted to the deployer and avoid the pain of trying to safely and securely do both when they conflict.
>
> The ability to limit it to the same project tree or a project you have roles in would be nice, but I fully agree that trying to introduce a connection here to Keystone could be a pain. If made as a another configuration option it could work possibly. Neutron already has a keystone admin user, and doing the required calls to keystone here wouldn't be too hard. Checking for the same tree is an easy upwards traversal, once root is reached, compare root for both projects, sadly more than one API call, but not too bad. User role checking is easy, and just a single call to the role assignments API. As for rechecking, I wouldn't bother. Projects can't be reparented, and while user roles can change it is mostly safe to assume that this network sharing was safe due to them having a role originally. No polling needed. My idea here was to do the checks, and if neither was true, then require acceptance.
>
> At any rate, even just an acceptance workflow would solve my core problem, but I'll write up the proposal for the full plan, and we can redesign from there!
>
> Regards,
> Adrian Turjak
>
>
> On 1/03/2017 9:27 PM, Kevin Benton <kevin at benton.pub> wrote:
>> Hi Adrian,
>>
>> Thanks for the write-up.
>>
>> I think adding an approval workflow to Neutron is a reasonable feature request. It probably wouldn't be back-portable because it's going to require an API change and a new column in the database for approval state so you would have to patch it in manually in your cloud (assuming you don't want to wait for Pike).
>>
>> The tricky part is going to be figuring out how to handle API backward compatibility. Requiring an extra step before a project is allowed to use a network shared to it would break existing automation that depends on the current workflow. 
>>
>>
>> Please file an request for enhancement against Neutron[1] and we can continue the discussion of how to implement this on the bug report.
>>
>>
>> As for your option 2, the reason Neutron can't do something like that automatically right now is due to a lack of strong Keystone integration. Outside of the middleware that authenticates requests, Neutron doesn't even know keystone exists. We have no way to prevent changes on the keystone side that would violate the current RBAC policies (e.g. a user is using a network that they wouldn't be able to use after a keystone modification). We also have no framework in place to even see keystone alterations when they happen so it would require constant background polling.
>>
>>
>> 1. https://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
>>
>>
>> Cheers,
>> Kevin Benton
>>
>> On Tue, Feb 28, 2017 at 7:43 PM, Adrian Turjak <adriant at catalyst.net.nz> wrote:
>>> Hello Openstack-Devs,
>>>
>>> I'm just trying to find out if there is any proposed work to make the
>>> network RBAC a bit safer.
>>>
>>> For context, I'm part of a company running a public cloud and we would
>>> like to expose Network RBAC to customers who have multiple projects so
>>> that they can share networks between them. The problem is that the
>>> network RBAC policy is too limited.
>>>
>>> If you know the project id, you can share a network to that project id.
>>> This allows you to name a network 'public' or 'default' and share it to
>>> others in hopes of them connecting to it where you then potentially
>>> compromise their instances. Effectively this allows honey-pot networks.
>>> The only layer of safely you have is first needing to gleam a project id
>>> before you can do this, effectively security through obscurity, which is
>>> a terrible approach.
>>>
>>> Ideally network RBAC should work the same as image sharing in Glance.
>>> You share a network, and the other project must accept it before it
>>> becomes usable. This doesn't stop a too trusting party from accepting an
>>> unsafe network, but it means they have some warning before doing
>>> anything silly. Otherwise the onus is on them to always be vigilant for
>>> shared networks that shouldn't be there, which is not exactly something
>>> we want our customers to have to worry about.
>>>
>>> Are there plans to implement some sort of acceptance process for network
>>> RBAC in Neutron, or a willingness to? Other options are to only allow
>>> sharing to projects you have a role in, or projects in same hierarchical
>>> 'tree'. If I throw up a spec/blueprint for this is there interest in
>>> following through with dev work, or would there be support if I or other
>>> members of our company decide to help implement such a change?
>>>
>>> If not, I've considered a few options I can do around this, and I'd be
>>> curious on people's thoughts:
>>> 1. Expose Network RBAC as is and setup automated auditing to check for
>>> shared networks policies outside of their hierarchical tree, or between
>>> projects that don't have shared users.
>>> 2. Build into our workflow service a new plugin to expose a neutron
>>> RBAC-like API which in the background uses the Neutron API with an admin
>>> account on your behalf. This service would enforce a level of custom
>>> policy that we'd want before allowing the creation of a network RBAC
>>> policy. That way networks can only be shared between projects in the
>>> same tree, or if the requesting user has roles in both projects. If
>>> anyone attempts to share beyond that scope, we will require an admin to
>>> approve the request before the network is shared, or simply deny it.
>>> Think of this as a wrapper/proxy around Network RBAC to allow
>>> stronger/flexible policy. In this scenario the Neutron policy would
>>> limit RBAC to admin only.
>>>
>>> Option 1 is easy, but reactive, which in larger deployments, or with
>>> larger customer bases isn't great since parsing that much data as a
>>> human is hard, and writing the auditing to tell us what is 'unsafe'
>>> correctly isn't easy. We may not always catch things fast enough, or
>>> we'll catch too much and have to process it.
>>> Option 2 is a bit more work, and means clients have to interact with a
>>> different API instead (which we'd document to our customers and provide
>>> a horizon panel for it), but gives us as deployers far more safety and
>>> security.
>>>
>>> So, what to do? Is it worth trying to make this feature safer in
>>> Neutron? Will we get the support to make it happen? Or should we just
>>> develop something around it so it works for us as we need it to? It's a
>>> very useful feature, but as it stands it's too unsafe to expose in a
>>> public cloud environment.
>>>
>>> Regards,
>>> Adrian Turjak
>>>
>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170303/540e5d53/attachment-0001.html>