VMWare vCenter, Create ROLE + USER/GROUP + OBJECT and assign full permission to exclusive resource pool

=================== SCOPE
 - Create User 'TEST',
 - User 'TEST' must have all permissions only to RESOURCE Pool assigned to 'TEST'
 - User 'TEST' will have Limited access to vCenter (role propagation requires so)

U - User
G - Group
R - Role
O - Inventary Object

==Enable Cluster DRS
Cannot create a Resource Pool in a vCenter Server cluster (1004098)
 - Cannot create a Resource Pool in a vCenter Server cluster
 - The New Resource Pool option is grayed out

Resolution: The option to create resource pools is disabled unless VMware DRS is enabled on the cluster.


==Create UGR
1. Clone role 'ROLE-TEST' from Admin
2. Customize role 'ROLE-TEST' as descibed below
3. Create group 'GROUP-TEST'
4.  Create user 'USER-TEST' and assign him to 'GROUP-TEST'

5. Add permission  'USER-TEST' or 'GROUP-TEST'  with 'ROLE-TEST' to vCenter and Datacenter(s)  !!!! (limited, ex: cancel task, create VM from existing)
6. Add permission  'USER-TEST' or 'GROUP-TEST'  with 'ROLE-TEST' to Resource Pool/vAPP
7. Add permission  'USER-TEST' or 'GROUP-TEST'  with 'ROLE-TEST' to Datastore (alocate Datastore for this user)
8. Add permission  'USER-TEST' or 'GROUP-TEST'  with 'ROLE-TEST' to Network(s) (from vSwitch)

=================== THEORY
vCenter Server and ESXi hosts use the same structured security model to allow users to manage portions of the virtual infrastructure
This model consists of users, groups, roles, privileges, and permissions:

USERS:      Group       ROLE         PRIVILEGES
admin1 -\  ........................... /- Power-ON VM
admin2 --> Admins-Gr -> Admins-role   <-- Open Console
admin2 -/  ........................... \- Power-OFF VM
|-> Resource-Pool: Web-Servers (inventory object)

 - Role is a collection of privileges.
 - From vSphere 5.1 onward, the architecture has significantly changed with the introduction of vCenter Single Sign-On (SSO).
 - ESXi can leverage either local users and groups or users and groups from Active Directory.
 - With only three built-in roles on ESXi hosts, the defaults don’t leave room for much flexibility. (No Access/Read-Only/Administrator)

 - Possible to create custom roles to better map to your business needs
 - Role are not functional until (1) a user or group is assigned to the role and (2) the role is then assigned to an inventory object as a permission.
 - Option named "Propagate To Child Objects" is enabled by default - allows the privileges assigned in this role to be applied to objects beneath the selected object
 - Resource Pools are not intended as a means of organizing VMs

 - Permissions may be assigned to all inventory items in vCenter including: Folders, Resource Pools, Networks (Port Groups), and Datastores.
 - By choosing to propagate or not propagate a specific Permission, administrators may enact very precise control over users, what items they can see and what they can do with those items.

Alternatives to "Propagate To Child Objects":
  - assign permissions on each of the 10 web server VMs individually
  - No Access role on the non-web-server VMs
  - Assigning Role to Object, un-select "Propagate To Child Objects"

 - non-propagating Permission at the Datacenter level,
 - propagating Permission for the Resource Pool, Network and Datastore

=================== EXAMPLE
 Minimum vCenter Privileges required for Cloud Computing:

Datastore - Allocate space
Datastore - Browse datastore
Datastore - Low-level file operations
Datastore - Remove file
Datastore - Update Virtual Machine Files

Datastore Cluster - Configure a datastore cluster

Global - Disable methods
Global - Enable methods
Global - Licenses
Global - Log event
Global - Manage custom attributes
Global - Set custom attribute

Resource - Assign virtual machine to resource pool
Resource - Apply Recommendation
Resource - Create Resource Pool
Resource - Remove Resource Pool
Resource - Rename Resource Pool

Virtual Machine - Add existing disk
Virtual Machine - Add new disk
Virtual Machine - Advanced
Virtual Machine - Change resource
Virtual Machine - Disk change tracking
Virtual Machine - Disk lease
Virtual Machine - Remove disk
Virtual Machine - Device connection
Virtual Machine - Guest operating system
Virtual Machine - management by VIX API
Virtual Machine - Register
Virtual Machine - Remove
Virtual Machine - Allow disk access
Virtual Machine - Allow read-only disk access
Virtual Machine - Allow virtual machine
Virtual Machine - download
Virtual Machine - Create snapshot
Virtual Machine - Remove snapshot
Virtual Machine - Revert to snapshot
Virtual Machine - Add virtual machine
Virtual Machine - Assign resource pool
Virtual Machine - Unregister

=================== Best Practice
Required Privileges for Common Tasks

VMware recommends the following best practices when configuring roles and permissions in your vCenter Server environment:
 - Where possible, grant permissions to groups rather than individual users.
 - Grant permissions only where needed. Using the minimum number of permissions makes it easier to understand and manage your permissions structure.
 - If you assign a restrictive role to a group, check that the group does not contain the Administrator user or other users with administrative privileges.
   Otherwise, you could unintentionally restrict administrators’ privileges in parts of the inventory hierarchy where you have assigned that group the restrictive role.
 - Use folders to group objects to correspond to the differing permissions you want to grant for them.
 - Use caution when granting a permission at the root vCenter Server level.
   Users with permissions at the root level have access to global data on vCenter Server, such as roles, custom attributes, vCenter Server settings, and licenses.
   Changes to licenses and roles propagate to all vCenter Server systems in a Linked Mode group, even if the user does not have permissions on all of the vCenter Server systems in the group.
 - In most cases, enable propagation on permissions. This ensures that when new objects are inserted in to the inventory hierarchy, they inherit permissions and are accessible to users.
 - Use the No Access role to masks specific areas of the hierarchy that you don’t want particular users to have access to.