VMware Cloud Community
kunalkhairnar
Enthusiast
Enthusiast
Jump to solution

vRO permissions - hardening RBAC, Security

Prerequisites:

1. vCenter Server instance is added in vRO using an administrator user account with full privileges (using the "Share a unique session" option while adding vCenter Server instance) on vCenter Server and full permissions in vRO.

2. The "vmuser" has fewer privileges e.g. the default "Virtual machine user (sample)” role on the vCenter Server and View, Inspect, Execute permissions in vRO.

Scenario:

The “vmuser” executes the vCenter Server workflow “Create simple virtual machine”.

The workflow execution completes successfully creating the specified virtual machine. However, the operations are executed in the context of the service account i.e. the administrator user account with full privileges used for adding the vCenter Server in vRO. Note that the “vmuser” has no permission to create a virtual machine and with execute permission in vRO the restricted user created a virtual machine.

Also observed that the Initiator reported in the Recent Tasks vs. More Tasks in vSphere Web Client are different.

vROCreateVM.png

What options are available if I want to execute the vRO workflow/operations in the context of the “vmuser” – the user that initiated the vRO Workflow instead of the service account used for adding the vCenter Server in vRO?

Appreciate your thoughts, suggestions, comments on this.

I think of few options:

1. Plug-in for vRO with Custom Workflows

2. Leverage vRO REST API retrieving vRO user, workflow/operation details and check against the vCenter Server privileges for the vRO user for allowing/disallowing the vRO workflow/operation.

1 Solution

Accepted Solutions
iiliev
VMware Employee
VMware Employee
Jump to solution

OK, what you are seeing is the expected behavior when using "share a unique session" mode. Administrator user name in the task console is the user who is used to execute the actual vCenter task. The entry in the recent tasks panel is not a vCenter task but a vRO workflow execution, so the vmuser name there is the account who has started the workflow (which eventually led to creation of the vCenter task on behalf of administrator user).

If you want full control over the vRO and vCenter operations, the first option to consider is to use "session per user" mode instead of "share a unique session" mode. In this mode, the same use who has logged in to vRO Client and who has run the workflow will be used by vCenter task, so you will be able to fine tune access control/permissions on both vRO and vCenter sides.

The downsides of "session per user" mode are:

  • it is not always possible to use it. Eg. if vRO is configured with vRA authentication, vRO will try to call vCenter API passing OAuth token which is currently not supported by vCenter.
  • it requires more work to assign the correct permissions; you need to assign permission on both vRO and vCenter sides, whereas in "share a unique session" mode you will need to set permission on vCenter side only for the service account

View solution in original post

2 Replies
iiliev
VMware Employee
VMware Employee
Jump to solution

OK, what you are seeing is the expected behavior when using "share a unique session" mode. Administrator user name in the task console is the user who is used to execute the actual vCenter task. The entry in the recent tasks panel is not a vCenter task but a vRO workflow execution, so the vmuser name there is the account who has started the workflow (which eventually led to creation of the vCenter task on behalf of administrator user).

If you want full control over the vRO and vCenter operations, the first option to consider is to use "session per user" mode instead of "share a unique session" mode. In this mode, the same use who has logged in to vRO Client and who has run the workflow will be used by vCenter task, so you will be able to fine tune access control/permissions on both vRO and vCenter sides.

The downsides of "session per user" mode are:

  • it is not always possible to use it. Eg. if vRO is configured with vRA authentication, vRO will try to call vCenter API passing OAuth token which is currently not supported by vCenter.
  • it requires more work to assign the correct permissions; you need to assign permission on both vRO and vCenter sides, whereas in "share a unique session" mode you will need to set permission on vCenter side only for the service account
kunalkhairnar
Enthusiast
Enthusiast
Jump to solution

Thanks, Ilian Ilievfor the detailed explanation and possible options!

I am curious about the options one can think of in case of using the "share a unique session" mode option i.e. the service account for the vCenter Server while adding in vRO. Any suggestions when vRO workflows run as part of the vRO Scheduler?

Reply
0 Kudos