Open Stack

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/20170301/ffa54d78/attachment.html>