vCenter rights needed for Docker-Machine vSphere Driver

There are many ways to quickly provision docker hosts to cloud infrastructures. Dockers own native way is to use docker-machine. Being a vSphere admin I was of course interested in the VMware vSphere driver for docker-machine.

The starting resources for this are:

https://docs.docker.com/machine/drivers/vsphere/

https://blogs.vmware.com/cloudnative/how-to-use-docker-machine-in-conjunction-with-vsphere-driver/

While I got this working, one of the issues I struggled with was vCenter rights. The driver wants to do a bit more than just create a new VM. For instance it needs to upload an ISO to the datastore to role the VM, and it needs to be able to manage the VM in different ways. And remove it.

I created a custom vcenter role for this purpose, but as the exact permissions where not listed anywhere, it was process of trail and error.

The debug switch -d is very useful during a 'docker-machine create' to identify which steps its going through exactly.

Replicating the steps in the vSphere flex client also helps, as that UI will usually give you a good indication what rights you are missing, either via a warning text, or a grayed option.  (remember log out and back in every time)

The vpxd log on the vcenter might help you see what is being tried, but I find it only partially helpful.

One issue that really killed me for a while, is that the account used by the docker-machine driver, requires not just 'browse datastore' and 'allocate space' permissions, but also 'low level file operations'

This is needed in order to upload (and delete) the boot2docker.iso

But it is not enough to apply these permissions only to the datastore, they must be applied to the entire vCenter scope, as per KB027743 , which frankly, is ridiculous. But that is an issue with vCenter rights model, not with the driver perse.

This takes are of vcenter rights overall. At least its better than applying full admin rights to the account you are using.

Down at resource level, in my case a specific cluster of 2 esx hosts, but it might also be a resource pool, I have applied full admin rights for the account.  This may be overkill, but it as far as I have gotten right now. I will update this post if I discover more nuance, or find some way to exactly inventory what rights its actually using the manage the VMs it spawns.