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
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
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
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
REST API
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.
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
With this we can create our Action
We will set Powershell as the runtime, and add our constants as 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)
10
11 $auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($inputs.vcUser+':'+$pass))
12
13 $authHeader = @{
14 Authorization = "Basic $auth"
15 }
16
17 $sessionResponse = Invoke-RestMethod -Method POST -Uri $sessionUrl -Headers $authHeader -ContentType "application/json" -SkipCertificateCheck
18 $token = $sessionResponse
19
20 $header = @{
21 "vmware-api-session-id" = $token
22 }
23
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)
27
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
44
45 $updateResponse = Invoke-RestMethod -Method PATCH -Uri $nsUrl -Headers $header -Body $body -ContentType "application/json" -SkipCertificateCheck
46 return $updateResponse
47}
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
Testing the deployment
Now let's test a deployment with permissions
After a while we can verify that our Action has run
And we can verify in vCenter that our namespace got created with the selected users and their role
Summary
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