Thanks to Daniel Vatov for your help on this blog!
vRealize Orchestrator 8.x provides a security model with different roles. As access to vRO is done through vRA roles and authentication, a mapping between roles on vRA side and vRO must take place. While this is described for vRA 8.x here, the same procedure will not work for vRA Cloud due to a different implementation. vRA Cloud is leveraging a specific version of vRO 8.x which is SaaS-enabled and called Cloud Extensibility Proxy.
This blog describes how to configure vRO roles and map them to roles of the cloud service portal connected to vRA Cloud.
Cloud Service Portal Roles
Assign Roles in Cloud Service Portal
Cloud Service Portal supports a variety of roles which refer to the single integrated cloud services.
In principle every role on CSP could be mapped to vRO roles however in most cases customers will want to map Cloud Assembly related roles to vRO due to the tight interaction.
Each role on CSP has an internal name code like “Cloud Assembly User” refers to “automationservice:user”.
Get internal role names
The internal role names cannot be seen from vRA Cloud UI directly. The best way to retrieve the roles for a distinct user is this one:
Log on as the user to CSP and vRA service if you are searching for a role there (use Chrome browser)
Use Keys Ctrl+Shift+I to let developer tools appear and navigate to network tab
Do some activities in e.g. vRA Cloud
Select one entry in developer window where “authorization: Bearer” is appearing and copy value from bearer token
Go to web page jwt.io and paste the bearer token in left hand box
In right hand box you will see the roles the user is assigned to with their internal name. All roles should be shown in “perms” property.
Map roles in Cloud Extensibility Proxy
To map one of the Cloud Extensibility Proxy roles to CSP roles the running pod configuration on the extensibility appliance must be modified.
First export the pod config into a yaml file
kubectl get vaconfigs.prelude.vmware.com -o yaml > vaconfig.yaml
Now edit the configuration file
vi config.yaml
and search for the section where the roles are defined:
You then can add one of the CSP internal role names as comma-separated items.
Like in the example above the “automationservice:user” has been added to the “viewerRoles” definition.
In this case my user vra-user@gmx.de has “Cloud Assembly User” role on CSP which is mapped to “viewer role” on Extensibility Proxy now.
Once the file has been modified the changes must be applied by this command:
kubectl apply -f vaconfig.yaml
Furthermore, a restart of the vRO services is required:
prelude-vami-upgrade –force
Wait a couple of minutes until the vRO services have come up and the interface is reachable again.
Verify user role on Cloud Extensibility Proxy
You can verify the role assigned when logging on to Cloud Extensibility Proxy. Just connect to https://<cloud-extensibility-proxy> and log in with your CSP credentials.
On upper right corner when clicking at the username you will see the assigned role. “User” in this case presents “viewer” role.
Groups in Cloud Extensibility Proxy
Independently to the roles mapping which provides general access permissions to Cloud Extensibility Proxy, it also supports “groups” functionality which allows for more granular permissions assignment. With that you can grant permissions to specific items/workflows.
Have fun!
- 1-node Kubernetes Template for CentOS Stream 9 in VCF Automation - 30. September 2024
- Aria Automation custom resources with dynamic types - 9. August 2024
- Database-as-a-Service with Data Services Manager and Aria Automation - 4. July 2024