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 <ke...@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 > <adri...@catalyst.net.nz <mailto:adri...@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-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@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 <ke...@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 <adri...@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-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
