I've just migrated this site to Jekyll, along with making use of VMware Clarity styling. Please excuse any formatting issues while I bed in the migration.

Creating Custom Roles for vRealize Automation

Over the last little while, I’ve been working with a pretty advanced customer of ours. This customer in turn has some pockets of even more advanced business units who have some needs that force me to be particularly creative.

Today’s first challenge was to invoke a vRO action via the vRA API. Not a workflow - just an action, and to return the output as validation for one of their pipeline tests. Enter my old frenemy, the API. If this is your first attempt to work with the API, I recommend you have a look at this post.

URI:
https://{{vra-fqdn}}/o11n-gateway-service/api/tenants/{{tenant}}/actions/{{folder}}/{{action}}/execute

METHOD:
POST

BODY:
The “entries” are the inputs required for the action, you’ll note that it is a list so it can support multiple arguments within each key/value block.

{
  "entries" : [
    {
      "key" : "keyName",
      "value" : {
        "type" : "string",
        "value" : "keyValue"
      }
    }
  ]
}

I tested this, and it ran a treat - the return included the output of the action and I was feeling rather pleased with myself.

Having overcome the first hurdle, I now moved onto the second (considerably trickier) challenge - only Tenant Administrators could execute the action without recieving authorization errors.

Setting permissions in vRO didn’t help - in fact the attempts to launch the actions weren’t even hitting the vRO log. After some thinking, I realised that since I was hitting the vRA API, this was going to be a matter of vRA permissions. Giving the users who needed to execute this Tenant Administrator permissions was not going to be an option, so I began to look at how I could assign custom permissions to them.

Before you read any further, a word of caution. DO NOT EDIT YOUR DEFAULT ROLES.
A second word of caution - DO NOT EDIT YOUR DEFAULT ROLES.

Since modifying the Tenant Administrator role wasn’t an option, I started investigating the process to create custom roles that I could bind permissions to.
Enter (again) my old frenemy the API.

URI:
https://{{vra-fqdn}}/identity/api/authorization/roles/INVOKE_VRO_ACTION

METHOD:
PUT

BODY:

{ 
  "@type" : "TenantRole", 
  "id" : "INVOKE_VRO_ACTION", 
  "name" : "Invoke vRO Actions", 
  "description" : "Used to allow the invocation of vRO actions through the vRA API." 
  "assignedPermissions": []
}

This creates the role in question, albeit with no permissions. Creating a group this way makes it show up in the UI, allowing it to be assigned to a user or group just as you would any of the built in roles.

The next step was to assign the same permissions to this role as the Tenant Administrator has, and then figure out which of those permissions were what allowed for the action to be requested. To do this, I performed a GET against the Tenant Admin Role.

URI:
https://{{vra-fqdn}}/identity/api/authorization/roles/CSP_TENANT_ADMIN

METHOD:
GET

I wish that I could say that the required permissions jumped out at me, but it wasn’t until I was very near the end of peeling one permission away at a time that I remembered that when creating custom properties, you can use external actions. So, I updated the body as shown below with the appropriate permissions.

URI:
https://{{vra-fqdn}}/identity/api/authorization/roles/INVOKE_VRO_ACTION

METHOD:
PUT

BODY:

{
  "@type" : "TenantRole",
  "id" : "INVOKE_VRO_ACTION",
  "name" : "Invoke vRO Actions",
  "description" : "Used to allow the invocation of vRO actions through the vRA API.",
  "assignedPermissions" : [
    {
      "id" : "MANAGE_PROPERTY_GROUP_DEFINITIONS_TENANT",
      "name" : "Manage Tenant Context Property Groups",
      "description" : "Create, update and delete context property groups within a tenant",
      "prereqAdminPermissions" : null
    },
    {
      "id" : "MANAGE_PROPERTY_DEFINITIONS_TENANT",
      "name" : "Manage Tenant Context Property Definitions",
      "description" : "Create, update and delete context property definitions within a tenant",
      "prereqAdminPermissions" : null
    }
  ]
}

With that, I was able to assign that role to the group of users who needed this capability and voila! Job done.

PS. DO NOT EDIT YOUR DEFAULT ROLES