Limiting User Scope and Permissions in NSX

There is a constant stream of new features added with each release of NSX, but not all of the original features have survived. NSX Data Security was one such feature, but VMware also removed the ‘Limit Scope’ option for user permissions in the NSX UI with the release of 6.2.0 back in 2015. Every so often I’ll get a customer asking where this feature went.

The ‘Limit Scope’ feature allows you to limit specific NSX users to specific objects within the inventory. For example, you may want to provide an application owner with full access to only one specific edge load balancer, and to ensure they have access to nothing else in NSX.

The primary reason that the feature was scrapped in 6.2 was because of UI problems that would occur for users restricted to only specific resources. To view the UI properly and as intended, you’d need access to the ‘global root’ object that is the parent for all other NSX managed objects. VMware KB 2136534 is about the only source I could find that discusses this.

REST API Calls Still Exist

Although the ‘Limit Scope’ option was removed from the UI in 6.2 and later, you may be surprised to discover that the API calls for this feature still exist.

To show how this works, I’ll be running through a simple scenario in my lab. For this test, we’ll assume that there are two edges – mercury-esg1 and mercury-dlr that are related to a specific application deployment. A vCenter user called test in the vswitchzero.net domain requires access to these two edges, but we don’t want them to be able to access anything else.

The two edges in question have morefs edge-4 and edge-5 respectively. For more information on finding moref IDs for NSX objects, see my post on the subject here.

In the NSX 6.4 API guide, you can find the relevant calls on page 103 and 104 under the ‘Manage NSX Roles for Users’ section. To begin, I’ll use a GET call to retrieve information about the user vswitchzero.net\test:

Above you can see that the XML section titled <resource> is what we’re interested in. This is the ‘GlobalRoot’ object in NSX that is the parent for all other scoping objects. This means that the ‘security_admin’ level of access for vswitchzero.net\test applies to all NSX objects under this NSX managers jurisdiction.

What we want to do is to replace the globalroot-0 resource with specific objects we want to grant access to. In this case, it’s only edge-4 and edge-5.

The API call we want to use is on page 104 of the NSX 6.4 API guide:

POST /api/2.0/services/usermgmt/role/{userId}

It’s important to note that a required parameter isGroup is needed in order for the call to work. Since this is an individual user and not a group, I will append ??isGroup=false to the end of the call. If you are using a group, you’d replace false with true. Here is the full syntax I used:

POST https://nsxmanager.vswitchzero.net/api/2.0/services/usermgmt/role/test@vswitchzero.net??isGroup=false

Note: I got 403 responses when running this POST call against a user that has already been assigned a role in NSX. For it to work, I had to remove the user from the NSX UI and allow it to be created as part of this process.

You’ll notice that in the body of the call I ensured the user was given the security_admin role. This is the only role that’s supported to be used in conjunction with limited access scopes. If any other roles are used here, the feature will not work correctly.

If the call is successful, you’ll get a ‘204 No Content’ response.

After refreshing the users list in the UI, we can see that the access scope column now displays the specific objects as opposed to ‘Global’.

After logging back in, we can see that the test user has access to nothing but the two edges we defined.

As mentioned, GlobalRoot access is required for several sections in the UI. An example is the host preparation page. Attempting to navigate here throws several access errors:

Other sections like the DFW and Logical Switches views seem to handle this limited scope more gracefully.

Conclusion

The question really becomes – “Should I use and rely on this feature in newer NSX releases?” And the answer as you might expect is “It depends”. In all my testing, this feature does seem to work correctly with objects like ESGs and logical switches, but it should be used cautiously. Because it was removed from the UI, there likely aren’t too many people using this feature. The UI sections lack polish for a user with defined access scopes, and it’s possible that other oddities may occur in future releases – especially as things move to the HTML5 client.

If you just want to provide some tightening up of permissions for internal staff, this may do the trick. If your requirements are more critical, say for a multi-tenant situation or compliance reasons, you should consider looking at third party products such as Hytrust Cloud Control or something similar.

I’ve recently started some internal discussions to see about getting this feature introduced officially again, but I’d encourage anyone with a use-case for this to submit a VMware feature request.