Comment 0 for bug 1669630

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.