Open Stack

Hi Product Team,

Another user story for you.


Regards,

Tom


-------- Forwarded Message --------
Subject: [openstack-dev] [Neutron] Security Worries about Network RBAC
Date: Wed, 1 Mar 2017 16:43:32 +1300
From: Adrian Turjak <adriant at catalyst.net.nz>
Reply-To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev at lists.openstack.org>
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev at lists.openstack.org>

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