Network RBAC acceptance workflow
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| neutron |
Triaged
|
Wishlist
|
Unassigned | ||
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 users 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_
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.
| description: | updated |
| Changed in neutron: | |
| status: | New → Triaged |
| importance: | Undecided → Wishlist |
| Ihar Hrachyshka (ihar-hrachyshka) wrote | #1 |
| Akihiro Motoki (amotoki) wrote | #2 |
| Adrian Turjak (adriant-y) wrote | #3 |
| Kevin Benton (kevinbenton) wrote | #4 |
| Adrian Turjak (adriant-y) wrote | #5 |
| Armando Migliaccio (armando-migliaccio) wrote | #6 |
| Kevin Benton (kevinbenton) wrote | #7 |
| tags: |
added: rfe-postponed removed: rfe |
A proposal here is to introduce a new API (new resource) for new approvable RBACs, then maintain both options for some time (allowing admins to opt out of the former via policy.json), then dropping the old API after some time (leaving the old api definition in api-ref for out of tree plugins to implement).
A proposal to introduce a new config option is not ideal because it introduces another point of api incompatibility between clouds.