kunalkhairnar
Enthusiast
Enthusiast

Possible options to leverage vCenter Server RBAC, Privileges from vRA with vSphere Endpoint

Jump to solution

Prerequisites:

1. vCenter Server instance is added in vRA (version v7.2) as a vSphere Endpoint using an administrator user account with full privileges on the vCenter Server.

2. The "vmuser" in the same vCenter Server has fewer privileges e.g. the default "Virtual machine user (sample)” role on the vCenter Server and entitled to a vRA Blueprint that provisions virtual machine(s).

Scenario:

The “vmuser” submits the Blueprint request that creates virtual machine(s) on the vCenter Server.

The Blueprint execution completes successfully creating the specified virtual machine(s). 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 vRA as vSphere Endpoint.

Also, note that the “vmuser” has no permission to create a virtual machine (it has the default "Virtual machine user (sample)” role on the vCenter Server) and with entitlement to Blueprint in vRA the restricted user created virtual machine(s).

What options are available if I want to execute the vRA Blueprint in the context of the “vmuser” – the user that initiated the vRA Blueprint instead of the service account used for adding the vCenter Server in vRA as a vSphere Endpoint?

Appreciate your thoughts, suggestions, comments on this.

Note: For example, vRealize Orchestrator has an option of using "session per user" while adding vCenter Server in the vRO. vRO with "session per user" mode the vRO workflow operations on the vCenter Server will be executed in the context of the actual vRO user that initiated the vRO Workflow instead of the service account used for adding vCenter Server in vRO. Is there any similar option available in vRA? (vRO permissions - hardening RBAC, Security)

1 Solution

Accepted Solutions
daphnissov
Immortal
Immortal

What is your use case? Why are you looking for this behavior?

In short, like nmshadey​ says, this really isn't possible normally as vRA executes these machine provisioning workflows under the context of the service account.

View solution in original post

0 Kudos
5 Replies
kunalkhairnar
Enthusiast
Enthusiast

Is it fine to assume that there is no possible option(s) available in vRA while adding vSphere Endpoint in order to leverage the vCenter Server RBAC, Privileges for the vRA operations?

Appreciate some vRA expert providing insight on this.

Thanks!

0 Kudos
nmshadey
Enthusiast
Enthusiast

There is no way to achieve this that I know of. vRA requires a single Administrator account to authenticate with the vCenter endpoint for all its operations.

vRA is designed to provide a layer of abstraction from the underlying endpoints. Also, the identity store used to authenticate Business Group users is in most cases different than for vCenter users.

This is actually quite secure since you can permission users to deploy and manage workloads within vRA without requiring any access to vCenter Server.

I can see where you are coming from through. I have done a couple of vRA deployments for companies that are not service providers using single tenancy and it would be nice to see the same user in vRA and the vSphere web client Smiley Happy

RanjnaAggarwal
VMware Employee
VMware Employee

Consider this secenario where we have provider and tenant, provider has infra hosted and tenant is the one who is going to consume it. These are two different solutions too. vmuser is the one who is just submitting the request from the portal and at the end vCenter Service account is needed to trigger this at vCenter Level. If you want to trigger everything only as vmuser then that user must have administrator right at vCenter Level as well use vmuser in vSphere endpoint credentials.

Regards, Ranjna Aggarwal
daphnissov
Immortal
Immortal

What is your use case? Why are you looking for this behavior?

In short, like nmshadey​ says, this really isn't possible normally as vRA executes these machine provisioning workflows under the context of the service account.

0 Kudos
kunalkhairnar
Enthusiast
Enthusiast

I appreciate each one of you for sharing your valuable inputs! It helped me to better understand what is technically feasible in terms of vRA initiated operations on a vCenter Server.

>>> What is your use case?

The use case is:

The vRA end user vmuser (in this e.g. with vCenter Server "Virtual machine user(sample)" role) requesting to provision a virtual machine gets denied by the security controls deployed at vCenter Server level knowing that the vCenter Server user vmuser (request vm provisioning from vRA) has no privileges to create a virtual machine.

I understand that vRA has request approvals that can be leveraged. However, consider this more like a Proxy Server safe guarding the vCenter Server with security hardening on workloads regardless of vRA, vRO or vSphere Web Client initiating it - with no manual intervention required leveraging a security policy in effect. 

As vRA request for the vmuser is served under the context of the service account at the vCenter Server level it's the highly privileged vCenter Server service account; that these vRA initiated operations are permitted though for the less privileged vmuser (with vCenter Server "Virtual machine user(sample)" role to start/stop VM).

>>> Why are you looking for this behavior?

There are few reasons to look for this behavior in my opinion:

Greater visibility - certain vCenter Server operations are instantiated as as part of User XYZ from vRA

Security hardening - Less privileged vCenter Server user should be denied based on vCenter Server level RBAC - I understand vRA has options to safeguard incoming user requests with approval

As I check this with vRO which has 'share a unique session' vs. 'a session per user' mode to access a vCenter Server instance. This allows 'a session per user' mode with token delegation vRO end user requested operations executed in the context of the vRO end user (instead of the User details - service account to access vCenter Server instance).

0 Kudos