Create vSphere Namespaces in Aria Automation with Permissions

In this previous post we created vSphere Namespaces with vRealize Automation. One thing missing was the ability to set permissions on the namespaces, and that is what we'll take a look at in this post.

We actually saw an example of how to do this in a previous post where with help of the vCenter API created the namespace with vRealize Aria Orchestrator.

The problem with that is that we didn't get a vSphere namespace resource in Automation we could work with, eg for Day 2 operations and lifecycle.

That could be also fixed with Dynamic Types and Custom Resources if we want to go with the Orchestrator way

In this post we will make use of the wast extensibility features available to us in Aria Automation

Cloud Template

Before looking at the extensibility let's make some changes to the Cloud Template to allow for adding permissions to a namespace

Cloud Template with permissions input

In this example we're accepting a user input for the OWNER and VIEW role

And after versioning the template and importing it in Service Broker we have the form updated with our new inputs

Service Broker form with permissions input

Event subscriptions

To add the permissions for a namespace we will fire an API call to the vCenter REST API after vRA has provisioned the namespace. To do that we will use one of the Event Topics available to us

Event Topics

The Kubernetes supervisor namespace post provision seems like a good candidate for our use case

A quick look at the Event Topic gives us the following properties, where at least the namespaceName would be something for us to use

Event Topic properties


To work with the permissions on our namespace we will make use of the vCenter API and the https://{api_host}/api/vcenter/namespaces/instances/{namespace} endpoint. The API reference can be found here or in the Developer center in your vCenter.

The API call will be done with the PATCH method and we will only provide the updated access_list in the body.

Before tying this up in vRA we will verify it with Postman (or any other REST API client). Note that the name of the namespace is the identifier, which we already know that we can get from the Event Topic.

Testing API call with Postman

Note that the API requires a session id, more information found in the developer reference above.

vRA Action

Now, let's finally set things up in vRA to make the neccessary API calls. In our previous posts we've used Aria Orchestrator, but for this post we will mix things up a bit and use an ABX action running our code with the Powershell runtime.

As mentioned above we need to authenticate with the vCenter API. To do this we need to provide a username and password with access. We will add this as Action constants along with the fqdn of our vCenter host

Action constants

With this we can create our Action

Create Action

We will set Powershell as the runtime, and add our constants as inputs

Action Inputs

Our Powershell code looks like the following

 1function handler($context, $inputs) {
 2    $vcHost = $inputs.vcHost
 3    $nsName = $inputs.namespaceName
 4    $owner = $inputs.customProperties["custOwner"]
 5    $viewer = $inputs.customProperties["custViewer"]
 6    Write-Host "namespace: $nsName"
 7    $baseUrl = "https://$vcHost/api"
 8    $sessionUrl = $baseUrl + "/session"
 9    $pass = $context.getSecret($inputs.vcPass)
11    $auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($inputs.vcUser+':'+$pass)) 
13    $authHeader = @{  
14        Authorization = "Basic $auth"  
15    }
17    $sessionResponse = Invoke-RestMethod -Method POST -Uri $sessionUrl -Headers $authHeader -ContentType "application/json" -SkipCertificateCheck
18    $token = $sessionResponse
20    $header = @{
21        "vmware-api-session-id" = $token
22    }
24    #$nsUrl = $baseUrl + "/vcenter/namespaces/instances/" + $nsName
25    #$namespaceResponse = Invoke-RestMethod -Method GET -Uri $nsUrl -Headers $header -ContentType "application/json" -SkipCertificateCheck
26    #Write-Host $($namespaceResponse|convertto-json)
28    $body = @{
29        "access_list"= @(
30            @{
31                "domain"= "vsphere.local"
32                "role"= "OWNER"
33                "subject"= $owner
34                "subject_type"= "USER"
35            },
36            @{
37                "domain"= "vsphere.local"
38                "role"= "VIEW"
39                "subject"= $viewer
40                "subject_type"= "USER"
41            }
42        )
43    }  | ConvertTo-Json
45    $updateResponse = Invoke-RestMethod -Method PATCH -Uri $nsUrl -Headers $header -Body $body -ContentType "application/json" -SkipCertificateCheck
46    return $updateResponse

A quick note on a few things.

The first few lines pulls out our Action inputs, like the vcHost, the namespace and the owner and viewer from the customProperties in the Cloud Template

On line 7 we're setting the Base URl

On line 9 we're pulling the password with the $context.getSecret() method

On line 11 we're creating a base64 encoded string consisting of username:password which we on lines 13-15 add to an object later used for requesting a token on line 17

The Authentication header created on lines 20-22 is setting the vmware-api-session-id with the token from the authentication API call.

The body for updating the permissions are created on lines 28 through 43. Note that we're only supporting the two roles, OWNER and VIEWER, and we're only supporting adding one user for either of the roles.

Finally we're sending the PATCH request on line 45

Event subscription

Next step is to tie the Action to an Event Subscription on the Event Topic we've decided on

Event subscription

Testing the deployment

Now let's test a deployment with permissions

Test deployment

After a while we can verify that our Action has run

Action Runs

And we can verify in vCenter that our namespace got created with the selected users and their role

vSphere namespace


With that we can now create vSphere namespaces with Aria Automation with permissions, as well as with VM classes and limits which we've seen in this previous post.

There's obviously stuff here that would need to be polished a bit before using in production. For instance we require both an Owner and a Viewer, what if the user only wants to set an Owner? And the Edit role is not supported with this code. The purpose of this post and the others in this series of posts has been to show possibilities, hopefully it can assist in some way or form.

And with that we're concluding this little series of creating namespaces. Thanks for reading

This page was modified on February 22, 2023: namespace permissions post