WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple
You are here: Home / vSphere Web Client / How to restrict vSphere UI access while maintaining vSphere API functionality?

How to restrict vSphere UI access while maintaining vSphere API functionality?

06.08.2021 by William Lam // 2 Comments

Although I come across a fair amount of interesting and challenging questions posed by our customers, I have to say this is certainly one of the more stranger question that continues to surface every so often. The question itself is fairly straight forward, but what I find strange is the reasoning and justifications for needing such a solution.

In case the title was not a give away, the question is having the ability to restrict a set of user(s) from the vSphere UI while still allowing access to the vSphere API for these same user(s). To be clear, the behavior of vSphere is that if you have vSphere UI access, then you also have vSphere API access which is all based on the permissions a user or group has been granted. There is no way to distinguish or limit access between these interfaces including any vSphere SDK or PowerCLI usage which also relies on vSphere API access.

There may be valid use cases for needing such a capability, however from my experience in talking with our customers and field, it feels like this is an attempt to solve organizational and/or process issues. Let give you a few examples that I have come across over the years:

  • I need to prevent [team|individual] from using the vSphere UI, because they are not using the internal provisioning tools we have built
  • I need to prevent [team|individual] from using the vSphere UI, because they need to learn how to automate using the vSphere API
  • I need to prevent [individual] in [team] from using the vSphere UI, because they are making changes to VMs without filing support tickets
  • I need to prevent [individual] on my [team] from using the vSphere UI, because they are bypassing our change control policies

Whether this surprises you or not, I guess the concept of wanting or being able to block a vSphere UI interface is not necessary new. In fact, I was reminded of this article which I wrote back in 2012 on blocking access to the vSphere C# Client, which was implemented quite a bit by customers to encourage usage of the vSphere Flex Client (RIP) but I certainly have heard customers using it for other reasons like the ones I had listed above.

In any case, I was recently reminded of this topic and for some odd reason, I started to ponder about a potential solution 😅. Perhaps it was due to some recent NSX-T firewall rules that I was creating on my VMware Cloud on AWS SDDC which involved specifying specific IP Address(s) which got me thinking along this concept ...

The vSphere UI runs as a Tomcat application and I was curious if there was a way to restrict access the vSphere UI endpoint (/ui) which would prevent users from accessing the vSphere UI while still preserving vSphere API access which is under the /sdk endpoint. A quick search online lead me to the Access Control Valve where you can control which remote client IP Addresse(s) are allowed or denied.

In the example below, I have used an allow rule and for any IP Address that does not match, you will see the following behavior where the vSphere UI screen will return a 403. However, when connecting to the vSphere API using PowerCLI, you will be able to successfully login.


Disclaimer: This is not officially supported by VMware and the configuration changes may not persist with future vCenter Server upgrades.

Step 1 - SSH to the VCSA and then edit /usr/lib/vmware-vsphere-ui/server/conf/context.xml and add the following entry:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost|x.x.x.x|y.y.y.y"/>

where x.x.x.x and y.y.y.y are IP Address(s) that wish to allow to connect to vSphere UI.

Note: Ensure that the "127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost" snippet is always included in the allow list which enables various vCenter Server services to communicate locally for proper vCenter Server functionality.

Step 2 - Restart the vSphere UI service for the change to go into effect:

service-control --restart vsphere-ui

More from my site

  • Updated vSphere Login UI customizations for vSphere 7.x & 8.x
  • vSphere Code Capture is your ChatGPT for vSphere Automation
  • Generating a vSphere UI link to a specific Virtual Machine
  • Creating custom ESXi images using vSphere Lifecycle Manager (vLCM) UI and PowerCLI cmdlets for vSphere 8
  • Why does Deploy OVF Template operation show vpxd-extension-[uuid]?

Categories // vSphere Web Client Tags // vSphere UI, vsphere web client

Comments

  1. sygibson+*protectednosbigys says

    06/08/2021 at 11:40 am

    William - interesting post, and pretty straight forward solution in general for Layer 7 policy control (in this case the API/URL path).

    We have a lot of similar requests for our product, which is 100% API first, but also has a rich Portal. In our customer use cases, they are building integrated management systems where they drive our product purely by the API. With our RBAC / Multi-tenant users accounts that have restricted access to only certain granted rights (roles) on the system.

    They want to prevent viewing of the management Portal with "all the options" that a user can't actually see. Oddly though - we do support customized Portal views based on Role. But in a lot of cases, they are also building a single Portal that manages a number of different products - so in this case, they are integrating with existing portal/management solutions.

    The use cases you outlined definitely sounds like a "fix our process problem" set of reasons, and not terribly sound technical reasons.

    Reply
  2. *protectedRobert says

    06/10/2021 at 6:39 am

    This solution is pretty cool. I can think of a use case where a backup product needs an elevated account(create/delete snapshots/VMs) but for security it would be nice to prevent that account from UI access. I don't believe this solution would work for this use case. Any thoughts?

    Reply

Thanks for the comment!Cancel reply

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

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VMware Flings is now available in Free Downloads of Broadcom Support Portal (BSP) 05/19/2025
  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025
  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025

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 © 2025

 

Loading Comments...