Milestone6:RBAC - echadbourne/SYS-350 GitHub Wiki

Part 1: Storage with NFS

Task 1

New datastore NFSshare

Go to datastores, right click on SYS-350, Storage > New Datastore > Select NFS

  • NFS 4.1
  • No kerberos
  • Attached to Super5 (none of the nested hosts)

Following configuration:

image

I then created a file called "super5.txt" by just echoing some text to a file with that name, like so:

  • echo "I am super 5" > super5.txt

Then uploaded the file to the NFS share by clicking "upload" and selecting my file

image

This didn't work the first time, I had to open the esxi console and accept the certificate to get it to work. I suspect the certificate had just expired since this management computer basically never turns off

Task 2

Create a second datastore, similar to the first, with these configurations:

image

Go through the process of deploying a new VM from a template, and make sure to select the Super5-NFS-VMs Datastore

image

Make sure to check if the vm is Thin Provisioned by clicking "customize hardware" and dropping down the hard disk

image

image

Cloned VM in the datastore:

image

At first it showed my new VM as orphaned, which was a little startling since I had problems with cloned VMs being orphaned when I created them in the past. That was related to my datastore not having enough room, so I was worried that someone had accidently filled up the space with a thick provisioned vm. This did not turn out to be the case though, as I waited a bit and as I was drafting my email it fixed itself, so I think the VM showed as orphaned while it was being created

Also, it shows the VM as being in both datastore2 and the NFS datastore, I'm not sure why it does that since I only selected the NFS datastore, but if it's in the shared folder (which it is) than I'm not too worried. I suspect it might have to do with having to select super 5 as the deploying host.

Part 2

RBAC

Create new folders and new AD users

{25CE7619-3185-47FB-96F1-B0B37C9C0B43}

Make sure to uncheck "User must change password at next login

{80847226-EAB1-4990-A93A-1F462898F508}

{261A291B-EFC2-4B0A-BC20-88853065ED0C}

Create two new AD groups (in AD Users and Computers, New > Group)

  • sys350-power-user (alice)
  • sys350-restricted-user (bob and charlie)

Adjust the Alice folder so that it has the following permissions:

image

Drag a VM to the alice folder, then verify that alice can only see that one VM:

image

Add another vm to the shared VM's folder, and add permissions so power users are "Virtual Machine Power User" and restricted users are "Virtual Machine Console User." At this point my setup looks like this:

image

This means that bob will not be able to take a snapshot of the vm, but he can see it

image

I didn't really have any problems with this section, which is why there isn't much reflection. It all seemed pretty straightforward. Create an AD group, then assign a specific vsphere role to that group for a specific folder.

Cloning Roles

Go to Administration > Roles > Select the role you want to clone, then press "clone"

image

Edit the cloned role to remove power on and off functionality

image

Edit the restricted user permission to use the new role, and now charlie cannot power on or off a vm in that folder

image

This was also pretty simple. clone a role that has most of what you need, but edit one small setting in it, then edit the permissions to reflect the new role

Security Implications

NFS is vulnerable because it can be easily intercepted or seen. There was no authentication needed for me to put files into the NFS, so if an attacker were to find a vulnerable NFS Server they could easily interfere with the files on there, either just seeing them, editing or changing them, or adding something malicious. Specifically, NFS version 3 provides less security and authentication features, meaning overall it is less secure than NFS version 4 or higher.