A Quick Lesson on vRA Entitlements

vRealize Automation provides a ton of granularity for roles and permissions, service availability, lifecycle management (e.g. day-2 operations). It essentially boils down to a set of logic that defines who can see and do any given task on any given resource. This can be as simple as a handful of configurations, or get as complex as you want it to be.

vRA’s Entitlements feature is just one of many ways to add governance and additional controls to your environment. Entitlements allow admins to create a set of policies that determine which services any given consumer can deploy and how they can [lifecycle] manage their services post-provisioning. The following entitlement options are available per Business Group User or Group.

• IaaS Blueprints
• PaaS / AppServices Blueprints
• XaaS Services
• Actions / Custom Actions (Day 2 Operations)
• Service Catalogs
• Approval Policies

Entitlements are created and managed under Catalog Management (Administration tab -> Catalog Management -> Entitlements) for all available services. It is important to note that entitlements are a REQUIRED function for service delivery (e.g. all services must be entitled at some level before they are available for consumption). Since this isn’t a HOW-TO post (see the vRA Live Install and Config videos and/or the vRA 6.0 POC Guide for a detailed how-to), here’s a summary of how to get from here to there…

 

 

 

 

 

 

 

 

 

 

Once an Entitlement is created, there are several options that will help you fine-tune exactly what gets entitled, who this entitlement effects, which actions are available, and whether or not component-level approval policies are in the mix. Again, tons of granularity here.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

In these examples, I created an Entitlement called “IaaS

Entitlement”, set the status to “Active”, and assigned available Business Group Users and Groups. Note: ONLY users and groups that are added to the active Business Group (Infrastructure tab -> Groups -> Business Groups -> Users) can be added to an entitlement. In the next tab (click “Next >”), i add the items that will be entitled to this policy. In this case I’m adding the entire “IaaS Catalog” service, a handful of individual (pre-existing) Catalog Items, and all the desired Actions. You can also choose to add just the parent catalog and desired actions, which will blanket-entitle all the catalog items that belong to the catalog. But if you want to configure unique approval policies per catalog item, you’ll need those items listed individually. Clicking update creates and immediately enforces the entitlement. The listed users will now see the entitled items in their Catalog view.

Side note: Approval Policies are handled per entitled item, including Services (parent), individual Catalog Items (child), and Actions (day-2). This means you can create approvals for very specific requests or actions for some serious governance. For example, I can choose not to require approvals when users request a test/dev machine with minimal resources, but I can enforce approvals when that user Destroys the machine. Better yet, you can simply remove “Destroy” action from the list and prevent users from seeing that option in the first place…and that goes for machines that have already been provisioned! This is actually a very popular use case among my Fed customers.

That’s not all.

IaaS services actually have another set of entitlements are are enforced per-blueprint. These settings are configured at the Blueprint level (Infrastructure tab -> Blueprints). Create or Edit a Blueprint and click on the “Actions” tab…

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This list shows all the actions that are available for the Blueprint even before Entitlements take place. So, for example, I can choose to disable “Destroy” here, which will prevent any user from being able to Destroy the associated machine, even if they’re entitled to do so.

Another great example is “Reconfigure”…

Several customers prefer to strictly enforce a machine’s configuration once it has been deployed. One option is to disable the Reconfigure Action from the appropriate Entitlement(s), or you can disable it globally for the specific Blueprint.

Let’s say, for example, there was a bug (or “feature”) discovered that occurred in certain situations — i don’t know…perhaps during a Reconfigure on machines that have RDM’s tied to them. You can disable Reconfigure for all the affected machines right here…and avoid that bug all together!

 

+++++
@virtualjad