vRA8 Roles, Permissions & Policies

With this post I would like to inform you on the way we Roles, Permissions and Policies [RRP] are designed within vRA8. While working with customers I realized there was some confusion and different expectations on how this was implemented. With help of some slides I would like to make it clearer and more consumable.

Let’s start with an overview! Notice I will only zoom into the effects on RRP in Identity Management, Cloud Assembly and Service Broker, as these are the most used services in vRA8.

Next step is to identify how we can map Users/Groups, Roles and Policies within these services. I therefore tried to match the colors in each slide to link items with services. Following slide will reflect this.

Having seen the items that we have available, we can dive into the more specific models for Identity & Access Management. Next two slides will give some insight in what users/groups can see and do in vRA8 (also very well documented).

One of the most straight forward user/role model is found in Cloud Assembly where users can have a limited amount of four service-roles. Explained in more detail here.

Over to the Service Broker where it is important to understand we are talking about policies here on different Broker features like Day-2, Approvals, Leases and Limits/Qoutas. It is also important to know we are applying policies that take effect on existing Deployments!

Main focus should be in understanding the effects on polices and how they are applied. Besides the summary in the slide I would also like to refer to this document that describes it in more detail, including examples!

Until now this was just a summary of what can be found on several other blogs and official documentation. Main goal of this blog was to create a one-slider visualizing it all. Check out the next picture!

Looking at the above picture it is important to know:

How to distinguish what users can do/see in the GUI, can do in Projects and can do within Deployments
A user must have at least a service viewer role so that they can access the service
Custom roles take precedence over the service roles
Custom roles can be assigned to users and groups in addition to their already existing service roles to provide an extra set of permissions
When a member of a project creates a deployment there might be more than one policy that applies to that deployment
Day-2 entitlements can be assigned to a default Project-Role (Member/Administrator/…), Custom-Role or direct User/Group (as of 8.11)
When using direct User/Group entitlements we need at least a Project and/or Custom Role to work with Deployments
Once a policy is defined, default actions are not in place anymore (for all users, expect the one entitled to the policy). Therefore it is important to create a super-admin beforehand!
Enforcement is Resource/deployment focused
Effective policy depends on enforcement type and scope
Result/Decision depends on enforcement type [hard/soft]

As you see, there is a lot of details to take into account and sometimes it’s just best to test-drive the different scenarios, and that’s exactly what I have done! The next sheet displays the most common scenarios you can combine showing which are usable or not and what it eventually brings.