Governance in VIO - restricting tenant's from breaking stuff (ie networking)

[virtman80]

Hi all,

We are currently looking at VIO with dVS networking on a test rig.  We have been able to set up a provider network, which maps to a VLAN on our physical network, allowing our imaginary tenant (project) access to the outside world.

A tenant user (ie non administrator) is NOT able to create a provider network (good thing) however, it seems standard (ie non admin) tenant users do seem to have the ability to delete thier provider network from within there own project (bad thing).

Is there a way to "lock tenant users down" ie preventing a tenant from deleting provider networks from within his or her project?  I see "roles" listed in the horizon dashboard, but i don't see anything relating to this in the VIO documentation.

Cheers!

[admin]

hmm this sounds like a bug in the role based access enforcement.

I will file a internal bugzilla item to track and fix this in next patch release of VIO i.e 2.0.1

thanks

arvind

[admin]

What version of VIO are you using?

[virtman80]

Hi Arvind,

Thankyou for your reply, we're using the latest version, 2.0.

I've actually found the line we needed to change on the controller node's config at /etc/neutron/policy.json:

delete_network":provider"rule:admin_only",

Adding this to the config seems to of done the job, in that now only admin users have the required permissions to remove provider networks.

I guess a follow up question I have in relation to this is: would we still be "supported" by VMware after changing config on the management nodes? In order words,  are we as customers allowed to customise VIO by making changes to config should we need to?

Cheers,

Matt

[admin]

In general, the problem is with supportability and unknown side effects of configurations. In this case, it seems straigthforward and you can do the changes. But remember when you patch VIO this change will get overwritten. But we will also fix and make the same change as you mentioned below so you will be fine.

In 2.0 we have established a mechanism were cusomter can recommend the config parameters they want to change and we can test those parameters. Once tested we will include those in our framework and you will be able to change those parameters without worrying about overwriting.