VMware Cloud Community
TheVMinator
Expert
Expert
Jump to solution

Creating RBAC for vRO

From what I can see, although vRO gives the ability to create permissions on who can run what workflow, it doesn't come with predefined set of roles that you can assign users to such as vCenter does.

I don't want to have to figure out for every single workflow how does that map to existing security policy and one-by-one determine what users should be able to run what workflows.

Has anyone thought of a way to create role based access control in vRO?  For example:

storage admins:  Can run workflows that interface with WFA, VIPR and VMware snapshots and virtual disks

network admins:  Can run workflows that integrate with network monitoring tools

VMware admins: Can run all workflows against vCenter

VMware operators:  Can run worfklows that perform reporting against vCenter and basic VM operations like removing CD rom drives, but can't make any other changes.

I'm using "share a unique session", so vCenter permissions don't apply, on the permissions on the service account that the unique sessions uses.  That service account has to have full admin rights in vCenter.

How can I create these "roles" in vRO so I can assign user accounts to them and then associate the workflow permissions with roles instead of individual users, like I would in vCenter?

Reply
0 Kudos
1 Solution

Accepted Solutions
cdecanini_
VMware Employee
VMware Employee
Jump to solution

Major service providers have their public cloud service operated with vCO using shared session. vCloud Director also use a single admin session if I recall well and now powers vCLoud AIr

As Burke mentioned if you front end the workflow it is secure.

Mapping the same roles as in vCenter is possible, I guess just not in your environment with different SSO servers. Since vCenter was in the first place only vCenter Orchestrator there was no need to duplicate functionality.

Since vRO is the orchestrator engine on vRA and since vRA has all the policy based / reservation model vRO it does not make sense to duplicate this functionality either.

It does not mean it is locked and prevent you from implementing it in vRO since it is not too hard to implement a small DB listing roles and associating these with permissions. This was how Lifecycle Manager (basically a role based self service portal running on top of vCO) was built.

It all depends from where your end users start workflows. If it is from vCenter then certainly vCenter should handle roles for vRO.

vCO is really a component of the vCloud suite released as part of vCenter and as part of vRA. These are IMO the two components that should address the roles functionality.

If my answer resolved or helped you, please mark it as Correct or Helpful to award points. Thank you! Visit http://www.vcoteam.info & http://blogs.vmware.com/orchestrator for vCenter Orchestrator tips and tutorials - @vCOTeam on Twitter

View solution in original post

6 Replies
cdecanini_
VMware Employee
VMware Employee
Jump to solution

It does not have to do it since vCenter or other Orchestrated software do it. As long as session per user is supported the credentials can go through and you will see the inventory and have the capabilities of the user you log in vRO with. This is the reason of the session per user.

The shared session was very useful for the companies that did not set up specific roles / permissions to end users and wanted to publish a workflow that would for example clone a VM from template without assigning rights to business users in vCenter. It is a bit like a "run as" and for this reason permissions need to be set at the workflow level to insure the end user has only access to this given functionality.

In the past we also had something called perspective where a vCO admin could assign a list of workflows to a given LDAP group. Now this has moved to vRA where you basically entitle groups for given workflows as you wish defining your own groups / roles. What you listed including starting operations in multiple orchestrated system can easily made available to a user group in vRA and you can fine grain defined which operations are available to them or not.

If my answer resolved or helped you, please mark it as Correct or Helpful to award points. Thank you! Visit http://www.vcoteam.info & http://blogs.vmware.com/orchestrator for vCenter Orchestrator tips and tutorials - @vCOTeam on Twitter
TheVMinator
Expert
Expert
Jump to solution

OK thanks.

It does not have to do it since vCenter or other Orchestrated software do it. As long as session per user is supported the credentials can go through and you will see the inventory and have the capabilities of the user you log in vRO with. This is the reason of the session per user.

The problem is that I have other requirements that mean that I need to use "share a unique session" - for example multi-mode and the need to use service accounts.  So I can't use session per user.  Also I don't have vRA licensed, and this one consideration alone can't drive that decision to use vRA.

Since I need to use "share a unique session", Does that mean then that there is no other option - I have to go to every single workflow one by one and assign permissions to every single user?  There is no equivalent to the vCenter "role" concept or way to mimic it where I can assign multiple users to a role - outside of upgrading to vRA?

Reply
0 Kudos
Burke-
VMware Employee
VMware Employee
Jump to solution

No, vRO does not have that type of construct... besides, if you have a bunch of workflows that are for a specific group of people, you should NOT be having them use the vRO Client to run them anyway. Use of the vRO client should be restricted to your Workflow developers.

If vRA is a no-go for you, then the best approach for presenting a subset of workflows to users would be to provide some other front-end that accesses vRO's REST API. One approach would be to look into Wavemaker since it's whole thing is to provide a web front-end to REST APIs Smiley Wink

If my answer resolved or helped you, please mark it as Correct or Helpful to award points. Thank you! Visit http://www.vcoteam.info & http://blogs.vmware.com/orchestrator for vRealize Orchestrator tips and tutorials - @TechnicalValues on Twitter
TheVMinator
Expert
Expert
Jump to solution

OK thanks for the explanation.  However I'm sorry that vRO is designed like this. 

There are a practically infinite number of things that someone that manages a VMware environment might want to do represented in Orchestrator.  So many that attempting to define all them in the permission of a separate front end tool is impractical.

In a large VMware environment with a large number of people performing VMware administrative functions, not everyone can be a full admin in vCenter - that would be a terrible security practice.  And they can't be given access to a tool that bypasses the security in vCenter by allowing "share a unique session".  Also creating permissions around every individual workflow in vRO is obviously impractical.

If in vCenter a company is following the principle of least privilege and assigning roles to groups, rather than individual permissions to users, which is a security best practice, it doesn't make sense not to have that ability in vRO.  The front end would be a good solution when my target for that it a group of sales people that all need to log in and run a workflow that emails them how many VMs their customer has in their vCenter folder.

But Why would I not want to be able to map the same roles and levels of permissions that I have in vCenter in vRO and allow admins that use the VMware environment to create scheduled, orchestrated workflows and use vRO features to automate the tasks they would normally do manually in vCenter, keeping the same permissions as vCenter, and doing it in a centralized manner such as with multi-node?

I can see a use for the web front end but it seems that design doesn't universally fit all scenarios, and I can't see a reason not to have a roles / groups construct in the client for those that could use it.

thanks for the explanation though!

Reply
0 Kudos
cdecanini_
VMware Employee
VMware Employee
Jump to solution

Major service providers have their public cloud service operated with vCO using shared session. vCloud Director also use a single admin session if I recall well and now powers vCLoud AIr

As Burke mentioned if you front end the workflow it is secure.

Mapping the same roles as in vCenter is possible, I guess just not in your environment with different SSO servers. Since vCenter was in the first place only vCenter Orchestrator there was no need to duplicate functionality.

Since vRO is the orchestrator engine on vRA and since vRA has all the policy based / reservation model vRO it does not make sense to duplicate this functionality either.

It does not mean it is locked and prevent you from implementing it in vRO since it is not too hard to implement a small DB listing roles and associating these with permissions. This was how Lifecycle Manager (basically a role based self service portal running on top of vCO) was built.

It all depends from where your end users start workflows. If it is from vCenter then certainly vCenter should handle roles for vRO.

vCO is really a component of the vCloud suite released as part of vCenter and as part of vRA. These are IMO the two components that should address the roles functionality.

If my answer resolved or helped you, please mark it as Correct or Helpful to award points. Thank you! Visit http://www.vcoteam.info & http://blogs.vmware.com/orchestrator for vCenter Orchestrator tips and tutorials - @vCOTeam on Twitter
TheVMinator
Expert
Expert
Jump to solution

Ok thanks for the input

Reply
0 Kudos