yahoo-eng-team team mailing list archive

[Adrian Turjak <adriant@xxxxxxxxxxxxxxx>]

Public bug reported:

Network RBAC is hugely useful, but the policy is too limited and as such
causes some potential security problems. It is either turned on for
everyone, or off. No in between, with the only limitation being no
wildcards for non-admins.

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 user to have to worry about.

This is particularly bad in a public cloud setting, less so in private
cloud.

The proposed fix is to add an acceptance workflow, and a new column on
the RBAC models to allow that.

There is no good way to make such a feature backwards compatible. As
such the easiest and probably best solution is to setup a config entry
that turns on acceptance for Network RBAC, with an initial default of no
acceptance workflow. Combine this with a deprecation warning that the
default would change to acceptance as default going forward, but would
give enough people making use of the no acceptance feature time to set
their configs to turn it off.

A further extension would be the addition of an auto-acceptance feature
which would be a second config setting (a list of possible conditions)
linked to a series of optional checks during Network RBAC creation where
if any of them are met, the Network RBAC policy is created without the
need for acceptance.

The two default conditions for this should be:
- User has roles in both projects attempted to share between.
- Both projects are in the same project tree.

The first, a role check is a single call to the role assignment API in
Keystone. The second is two API calls to project detail with
"parents_as_ids=true" for both projects, and comparing if there is a
matching ID in the two parent paths that isn't the domain. Both are
simple enough and will not add much additional time, but will allow a
nicer UX than always requiring acceptance.

Since Neutron has an admin user to be able to validate tokens, using it
as well to do these checks shouldn't be much of a stretch.

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: rfe

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1669630

Title:
  Network RBAC acceptance workflow

Status in neutron:
  New

Bug description:
  Network RBAC is hugely useful, but the policy is too limited and as
  such causes some potential security problems. It is either turned on
  for everyone, or off. No in between, with the only limitation being no
  wildcards for non-admins.

  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 user to have to worry about.

  This is particularly bad in a public cloud setting, less so in private
  cloud.

  The proposed fix is to add an acceptance workflow, and a new column on
  the RBAC models to allow that.

  There is no good way to make such a feature backwards compatible. As
  such the easiest and probably best solution is to setup a config entry
  that turns on acceptance for Network RBAC, with an initial default of
  no acceptance workflow. Combine this with a deprecation warning that
  the default would change to acceptance as default going forward, but
  would give enough people making use of the no acceptance feature time
  to set their configs to turn it off.

  A further extension would be the addition of an auto-acceptance
  feature which would be a second config setting (a list of possible
  conditions) linked to a series of optional checks during Network RBAC
  creation where if any of them are met, the Network RBAC policy is
  created without the need for acceptance.

  The two default conditions for this should be:
  - User has roles in both projects attempted to share between.
  - Both projects are in the same project tree.

  The first, a role check is a single call to the role assignment API in
  Keystone. The second is two API calls to project detail with
  "parents_as_ids=true" for both projects, and comparing if there is a
  matching ID in the two parent paths that isn't the domain. Both are
  simple enough and will not add much additional time, but will allow a
  nicer UX than always requiring acceptance.

  Since Neutron has an admin user to be able to validate tokens, using
  it as well to do these checks shouldn't be much of a stretch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1669630/+subscriptions