vCenter Server Granular Permissions (v5)

[davidl]

Hi ,

Is there a way to apply these permissions at a Folder/ Resource and Datastore level instead of at the vCenter Server level itself ?

When I try to apply the permissions how I would expect to at a VMware level I can't view or backup any of the VM's in the folders I have set the test user to have permission on (but I can see an empty Folder when creating a new backup)

As a test I tried to run the backup anyway and it connects to the vCenter, doesn’t see any VM’s and then reports back a success.

If I take the same permissions and place them at one of the vCenter Servers Levels of the permission tree the Role I created works but not when I try to specify precise folders.

Thankyou for any help you can provide

[Vitaliy S.]

Hi David,

Yes, that should be possible, but make sure you apply these permissions on all objects that belong to a chosen Folder/Resource Pool. You need to switch to datastores, network and host and clusters views within vSphere Client and specify these permissions individually on all related objects, should help.

Thanks!

[davidl]

Hi Vitality,

Thankyou very much for your reply, and sorry for my delay and getting back to trying this I was side tracked by another implementation project.

I have since come back to revisit the POC and what I found is that I can certainly control things from a granular perspective within ESX so that the Veeam connector account only sees what I want that demo customer to see. However there was a catch which I only came across whilst playing around a bit.

Essentially it seems that the Veeam connection needs at least read-only access defined within the permissions of one of the hosts (anything above a host level works too but I found a single host most appropriate so far).

Once this was done everything from a Veeam perspective fell into place , I could see only the Datastores I had defined for the user , the appropriate Resource Pool, Folders and VM targets for my backups ( without being able to see anything else within the environment)

We now have quite a series of tests to run through but this is a huge step forward for the proof of concept

I will be sure to report back findings so that anyone else interested can see the results

Can you see any issues or introduced limitations by only defining the user on one ESX host as appose to all of them? When I tried any higher level such as Cluster, Datacenter or VC The user could see too much with-in Veeam and defining a manual deny for each folder I don’t want the user to see is not practical

Regards,

David

[Vitaliy S.]

Hi David,

Essentially it seems that the Veeam connection needs at least read-only access defined within the permissions of one of the hosts (anything above a host level works too but I found a single host most appropriate so far).

Yes, indeed. While I was working on granular permissions list I was applying them on vCenter Server level only, as I assumed it should be the case with low level objects too.

Can you see any issues or introduced limitations by only defining the user on one ESX host as appose to all of them? When I tried any higher level such as Cluster, Datacenter or VC The user could see too much with-in Veeam and defining a manual deny for each folder I don’t want the user to see is not practical

The only thing that may brake your backup/replication jobs is a vMotion task, as in this case VMs will be re-registered on the host, where you might not have enough permissions to backup/replicate VMs added to the job.

Thanks!

[davidl]

Yes I found that out yesterday hehe :p I also hadn't noticed when I posted my reply but there were 2 VM's that should have been there that I couldn't see within Veeam ( because they were on another ESX host within the cluster)

For now I have defined the permission on each ESX host as if I try to go any higher the end-result is not ideal for this test case.

The ideal scenario would be to add the permissions at the vCenter level but the purpose of this proof of concept is to test the viability of Customers within a hosted platform to run and manage Veeam for their own backups and by doing that the customer simply sees too much atm.

In essence I want to answer if Veeam be run and managed by the customer within a Multi-Tennant cloud environment safely ( provided certain minimalistic needs are met ). From a provider perspective the data is replicated and backed up using Veeam however more and more customers want to move away from things like Symantec Backup Exec or System recovery and have asked about running Veeam themselves

With the permission defined at the host level my connection to the vCenter from within Veeam and the ability to add/browse VM's within the job is showing exactly the data I'm after though I'm sure I'll hit a few walls lol .

Now I just have to work through all the other testing : D

[DaxUK]

Hi,

Just wanted to ask a couple of questions regarding this post.

We are attempting to do exactly the same as David is attempting with a multi-tenant environment and this post has been most helpful in getting this working.

Couple of questions:

1. Why is the read-only permission required on the host (or vCenter) to allow Veeam to see the VMs to be backed up when we have specified the V6 granular permissions required on the resource pool/Datastore to carry out the backup?

2. The reason why this is such a big issue is that although we can see only what is required in Veeam and backups work fine, if the client decided to install vSphere client and login to the vCenter using their supplied credentials they have read-only permissions to all hosts including performance data, all configuration data and most importantly access to tasks and events which list not only the events for VM's they have been given access to but all VM's on the host although these are greyed out.

As you can imagine this is not desirable and there is no way to stop them logging in with vSphere client instead of Veeam as they both use port 443 for access to vCenter server.

David, did you manage to get around this issue somehow or discovered any others?

Regards
Dave Wells

[Vitaliy S.]

Hi Dave,

Why is the read-only permission required on the host (or vCenter) to allow Veeam to see the VMs to be backed up when we have specified the V6 granular permissions required on the resource pool/Datastore to carry out the backup?

This is the requirement of vStorage API, which cannot be controlled from our side.

See existing topic with the same question: Permission requirements for replication in Veeam 6.1

Thank you!

[DaxUK]

Hi Vitaliy,

Thanks for that, it makes perfect sense now that you are using the vStorage API to view VMs.

We are now approaching this from the angle that we will never supply the vCenter credentials to the client and when they are setting up their Veeam Manager we will log onto their box and enter the credentials in the GUI for them.

With this method we have a question:

I have seen from this post that Veeam uses a machine-specific encryption key when storing the saved passwords in the Veeam database.

Migrating B&R to new/64-bit server?

Our auditor has asked the question is there anyway for the client to recover these passwords from Veeam? And do you have any technical specs on the encryption method used?

Regards
Dave Wells

[Vitaliy S.]

I'm not aware about technical specs, all I know is that Microsoft's cryptography application programming interface (API) is used. Pretty standard approach.