vSphere Permission cleanup

Your vSphere environment is a living environment. Inventory objects are created and removed all the time. Together with these inventory objects there are often security permissions that come along. Team X needs Power User access for all VMs in folder Project-X. But the life-cycle management of these permissions is often not as fluent as your VM life cycle management. There is no built in permission cleanup method.

As a result, old permissions might be left behind, and what is worse, redundant permissions might be present. This doesn’t make the task of investigating “Who can do what?” in your vSphere environment any easier.

With the help of the function in this post you can now get rid of all these redundant permissions!

The Script

Annotations

Line 24-25: the function accepts one or more vSphere Inventory objects, as a parameter or through the pipeline

Line 29-70: this is the internal function that does the actual work. The main function is just a wrapper to handle (and eventually convert) the parameter.

Line 39-40: the function recursively descends the inventory tree, and it checks the permissions on each node against the recursive permissions that were assigned in nodes higher up in the tree. To check what is there and what can be removed, the arrays $removePermission and $newParentPermission are used.

Line 44-45: in the current version of the function, the Principal and the Role need to be match, before the permission is considered to be removed

Line 58-64: if redundant permissions were discovered on the current node in the vSphere inventory tree, then the redundant permission will be removed. Or if the WhatIf switch was used, a message will be displayed.

Line 68: the internal function is called recursively for each child of the current node. The permissions that were already encountered on the parent nodes, are passed as a parameter to the internal function.

Line 77-79: a “cheap” implementation of OBN

Sample Usage

The use of the Optimize-VIPermission function is quite straightforward.

As a test environment, we applied some permissions on two different node in the tree. In this case for the Principal LOCAL\test.

In its simplest form, you just pass the name of the object where the optimization should start. Notice how we used the WhatIf switch on the function call. No actual permissions will be removed, but the function will show what it would do.

And this produces the following output.

The function also accepts multiple starting points, you can pass multiple locations on the Entity parameter.

The function output now shows the following (because we added a second redundant permission in the tree under Test2).

And you can use the function in a pipeline construct, like this.

Which produces exactly the same output as the previous example.

Note: it is strongly advised to always run this first with the WhatIf switch. Only when the WhatIf switch is not used, or when it receives a $false value, will the redundant permissions actually be removed!

Enjoy!

Leave a Reply

Your email address will not be published. Required fields are marked *

*
*

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