WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud
  • Tanzu
    • Application Modernization
    • Tanzu services
    • Tanzu Community Edition
    • Tanzu Kubernetes Grid
    • vSphere with Tanzu
  • Home Lab
  • Nested Virtualization
  • Apple
You are here: Home / Why is there a "No access" vSphere Role?

Why is there a "No access" vSphere Role?

12.10.2013 by William Lam // 5 Comments

vSphere's (vCenter Server & ESXi) authorization system includes several pre-canned Roles such as Read-Only, Administrator and Virtual Machine Administrator as an example. One of the roles that has intrigued me for awhile which is the "No access" role. This seems to be a really odd role to have, I mean what would you do with such a role if it does not have access to anything?

In a conversation I had last week with a fellow colleague, the "No access" role made its way into the conversation and I learned that there was a specific use case for this role, however it was unclear what that might have been. This go me interested and I decided to reach out to some folks to see if I can get to the bottom of this and the use case associated with it.

It turns out there are some customers who have some very interesting requirements in which they need to separate out users who have the Administrator role and prevent them from seeing and performing operations on specific vSphere Inventory objects. An example of this would be a vCenter Server with 4 vSphere Clusters where Admin1 can only see the first two Clusters and Admin2 can only see the last two Clusters and both users have the Administrator role.

To accomplish the above example, you can leverage the "No access" role in the following manner. As the "Uber" Administrator, you would assign both Admin1 and Admin2, lets call them Alan and Cormac the Administrator role at the vCenter Server level. This will grant them full access to the entire vSphere Inventory.

Now, to prevent Alan from seeing Cluster 3 & 4, we need to go into the Cluster object and add the "No access" role to both those objects. We do the same for Cormac but for Cluster 1 & 2. If we now login as the user Alan, we will see that only Cluster 1 & 2 are visisble.

If we login with the user Cormac, we can only see Cluster 3 & 4 as expected.

Although this may not be a common request in your environment, I can see some interesting use cases for having such a setup like on-boarding a new junior admin and wanting to provide them Administrative access to particular Clusters and removing the views for others they should not have access to.

I would like to thanks Rupam from our GSS organization for sharing the reasoning behind "No access" as well as a specific use case for the feature.

More from my site

  • Intel NUC 9 Pro & Extreme - First "Modular" NUC
  • Supermicro E300-9D (SYS-E300-9D-8CN8TP) is a nice ESXi & vSAN kit
  • New VMware Configuration Maximum Tool
  • PowerCLI script to help correlate vCenter, ESXi & vSAN build/versions w/o manual VMware KB lookup
  • VM serial logging to the rescue for capturing Nested ESXi PSOD

Categories // Uncategorized Tags // esxi, no access, permission, role, vSphere

Comments

  1. jasonboche says

    12/16/2013 at 6:11 pm

    Alan and Cormac - those names ring a bell.

    Reply
  2. Fabrizio de Luca says

    12/16/2013 at 11:55 pm

    This is what we - as VCIs - teach every week to students during ICM, FT and WN courses... =))

    Another use case is when you want to provide an external consultant with a vIPMI/vILO -like access to a single VM in case he/she messes up the VM networking connectivity.

    In this scenario you grant him/her:
    1. "No Access" role at the vCenter Server level (propagating the role to child objects).
    2. "Read Only" role at the specific VM level.

    Once logged in, the consultant will only see that specific VM and the "Read Only" role will let him/her access the VMRC in case of an emergency.

    Reply
  3. Sean Dilda says

    12/17/2013 at 2:07 am

    I've used 'No Access' almost since day 1. There's a couple other use cases I've run across.

    1) Assigning roles for automation programs. If a program is only supposed to act on a single cluster, why not hide the other clusters so that you can minimize the impact of potential programming glitches? Likewise, when test and prod are sharing a vCenter and they're keying off of inventory names, 'No Access' can make sure test can't see prod's resources (and vice versa) so you know they don't trample on each other

    2) Its a good way to keep people from asking why they can't put VMs on the datastores labeled 'local' 🙂

    Reply
  4. Grant Orchard says

    12/17/2013 at 11:26 pm

    Hey William, also useful if you don't want objects to be managed by vCOps.

    Reply
  5. Emanuele says

    05/18/2015 at 1:25 pm

    Hello, can you help me with this: https://communities.vmware.com/message/2508130#2508130 ?
    Thanks,
    Emanuele

    Reply

Thanks for the comment! Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search

Author

William Lam is a Senior Staff Solution Architect working in the VMware Cloud team within the Cloud Infrastructure Business Group (CIBG) at VMware. He focuses on Cloud Native technologies, Automation, Integration and Operation for the VMware Cloud based Software Defined Datacenters (SDDC)

Connect

  • Email
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • Vimeo

Recent

  • Self-Contained & Automated VMware Cloud Foundation (VCF) deployment using new VLC Holodeck Toolkit 03/29/2023
  • ESXi configstorecli enhancement in vSphere 8.0 Update 1 03/28/2023
  • ESXi on Intel NUC 13 Pro (Arena Canyon) 03/27/2023
  • Quick Tip - Enabling ESXi Coredumps to be stored on USB 03/26/2023
  • How to disable the Efficiency Cores (E-cores) on an Intel NUC? 03/24/2023

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2023