vCenter Services monitoring using vCenter API

Recently, I came across a use-case, where there was a requirement to create an in-house dashboard (visualization) to monitor anything-VMware. As part of this project, it was decided that the vCenter Services’ status needs to be captured as well and so there I was, wondering if the “API Explorer” that is now embedded as part of the “Developer Center” feature of the vCenter Server could be of any help?

So, I navigated through to the services category of the vcenter API, as “administrator@vsphere.local“.

When I execute the GET call against /api/vcenter/services, it did eventually return all of the vCenter Services with its respective statuses as shown below.

Easy, right? Actually not. I was tasked to do this with a read-only user instead of administrator@vsphere.local. It was then I realized, I had gotten a chance to blog about something, lol 😀

Per the community article here, there are no special API permissions required and based on the permissions assigned to the user (who executes the API) on vCenter, they should be able to retrieve information. So in my case I had granted the user read-only permissions on vCenter and propagated it to the children as well.

So my expectation was this user should now seamlessly be able to retrieve the service status as it was a read-only operation on the vCenter, but it wasn’t meant to be 🙁 I was not able to execute /api/vcenter/services. The response I received was:

{
    "error_type": "UNAUTHORIZED",
    "messages": [
        {
            "args": [],
            "default_message": "Unable to authorize user",
            "id": "vapi.security.authorization.invalid"
        }
    ]
}

So, I immediately tried the usual hack of adding this user as part of the Administrators group 🙂

And voila, it worked!

But this isn’t what I wanted to achieve, because this would violate the permissions assigned to the user and they can literally do anything on the vCenter. I had to enable only a read-only user to do the same operation. So with the help of GSS, I got to know the workaround for this.

All you have to do is to add the user to the “SystemConfiguration.ReadOnly” group, instead of the Administrators group.

And now, when I execute the API call, I get the response as expected. And I wrap this up with the screenshot of a successful execution after adding the user to the system configuration read only group.

Happy learning, folks!