The second part of this topic in the “vCloud Director Identity and Access Management” series touches the “per Org VDC” permission feature. I decided to split the topic into a multi-part series due to the length of the original one. The first part can be found using the link below:
vCloud Director Identity and Access Management – Part 1
Org VDC permissions
The “per Org VDC ” permission feature was recently brought up by my co-worker while he was working on a customer case that required a level of separation that goes beyond using roles with limited rights and vApp sharing. The feature was originally mentioned by Tomas Fojta in his 2016 post “Organization VDC Permissions in vCloud Director“, which was a new feature in the v8.10 release.
In his post, Tomas describes the use case as:
In one Organization there are multiple Org VDCs belonging to different business units. Each Org VDC has its own Organization VDC administrator (from the business unit) who can manage Org VDC resources (networks, Edge Gateways) in his Organization VDC but does not see VDCs of other business unit.
That sums up the use case pretty much. I other words, a clear separation of permissions between Org VDCs.
You could (as I did), wonder if the same can be accomplished by using roles with limited rights in combination with vApp sharing. My conclusion is that it’s not possible. If you need to also manage external / overlay networks, DFW or Edge Gateways here is no way to narrow it down to a specific Org VDC.
In the case you need manage VM’s, vApps and Catalogs only and your service provider or other business unit manages everything else, the sharing option could probably work out for you.
Since the actual configuration is already described by Tomas, there is no need to do that again. The actual configuration still has to be performed by using the API (tested up to v10). In a future vCD version, the feature hopefully can be configured in the UI.
Since the original post was based on the vCD Flex (flash based) UI, I can confirm that after the API based configuration has taken place, the feature also works perfect in the modern HTML5 (H5) UI.
In the example configuration Tomas provided in his post, he assumes using 2 local vCD user accounts and that each of them will manage their respective Org VDC. As being mentioned in the feedback on the post, you can also use local groups instead of users.
If you already have groups within the federated IdP, you can use those for the “per Org VDC” permission feature. Before doing so, the new “Org VDC Administrator” role must be created by the service provider in the form of a “Custom Global Roles” or by the tenant as a “Tenant Role”.
If the “Org VDC Administrator” role is available, import the federated group by going to “Administration” in the hamburger menu > Access Control > Groups > Import Groups.
Advised usage for Org vDC permissions:
- The main advantage is that non-VM tasks like managing networks and Edge Gateways now can be configured per Org VDC.
- To be used in a situation where 2 contractor or business unit each manage their own Org VDC within the same vCD Organization.
- If used, the configured amount of user / group references per Org VDC should be less than 200.
Hopefully this post give you insights in which features are available to implement a suitable IAM solution for your company within the vCD feature.
Use the ability to create Customer Global roles as a Service Provider or create your own as a tenant of the platform. Also make use of the Owner and Sharing options to secure access to vApps further more and / or use per Org VDC permissions to delegate control.
From my opinion configuring your Organization to be federated with your corporate IdP solution is a no-brainer. This is the only feasible option to use corporate user accounts, passwords, groups, password policies and MFA solutions.
This section contains the link that are relevant to this part of the series.