VCP6.5-DCV Objective 1.1: Role-Based Access Control - Section 1: vSphere 6.x Security - CustomNet VMware Research Jump to content

Study Resources for the VCP6.5-DCV

Helpful links to prepare for the VCP6.5-DCV exam
Read more

VCP6.5-DCV Objective 1.1: Role-Based Access Control

Still under construction but the first blog post in a series to break down each objective for the VCP6.5-DCV exam
Read more

VCP6.5-DCV Objective 1.2: Secure ESXi and vCenter Server

Not yet in development but the second blog post in a series to break down each objective for the VCP6.5-DCV exam
Read more

VCP6.5-DCV Objective 1.3: Configure and Enable SSO and Identity Sources

Not yet in development but the third blog post in a series to break down each objective for the VCP6.5-DCV exam
Read more

VCP6.5-DCV Objective 1.4: Secure vSphere Virtual Machines

Not yet in development but the fourth blog post in a series to break down each objective for the VCP6.5-DCV exam
Read more
Sign in to follow this  
Eric

VCP6.5-DCV Objective 1.1: Role-Based Access Control

Recommended Posts

This post is under construction. It will begin as a bookmarking page and evolve into a guide using screenshots of example steps taken in the Hands-on-Labs. Last updated: October 7, 2017.

VCP6.5-DCV Objective 1.1 Configure and Administer Role-Based Access Control

Role-based access control (RBAC) is what enables less experienced or trusted users to take part in the vSphere environment with limitations on what they can see and do. These limitations can gradually be lifted, approaching the full King King rights attributed to what the vsphere@administrator.local account is able to do by default. Keith Barker's joke and explanation for this term in his CBT Nuggets series is "Where does King Kong sleep at night? -- Anywhere he wants. He's King Kong!" 

It is a best practice to avoid disclosing access to the vsphere.local account unless it is absolutely necessary. The passwords to these accounts should be complex and changed often. Even if a group of fully-trusted administrators should have King Kong rights, it would be best to deny them vsphere.local access because otherwise would be no accounting for actions which they made while logged on to those accounts. It would be better to assign an administrator role with full-access to privileged accounts. This way audit logs will show exactly which user did what.

For this article, I will be using a free Hands-on-Lab to generate the screenshots. To try it yourself, simply go to VMware Hands-on-Labs, search for  onto HOL-1810-01-SDC - Virtualization 101: "Introduction to vSphere", and then log on with a my.vmware.com account (the same one you would use to log onto the VMware forums or download an evaluation copy but not for certifications. You can extend the time each hour to have up to 9 hours, and can repeat it indefinitely.

 

#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.

Video showing how to create a role and assign it to a group (VMware Tech Pubs, September 30, 2017):

Helpful links:

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

×