In this two part post I discuss and cover how to audit vCenter permission using PowerCLI. How to enumerate basic permissions and then expand it out and send it to a CSV file for further auditing. In Part 2, I’ll discuss how to create custom alerts using PowerCLI to trigger an event on a vCenter permission modification.
Part 1 -- Auditing vCenter Permissions
Reviewing and auditing vCenter permissions has always been awkward at the best of times. Unless you’re on top of permissions from day one, over time you can be left with a mess of vCenter permissions. If you’re not explicitly looking for it you won’t know it either. This is certainly what I found recently in one of my vCenter environments.
There are a few different ways to view permissions in the C# and Web Client. You can click on an object and view the Permissions tab or you can go to Roles. The Roles section is certainly much more useful but still far from ideal. You have to click on each Role and there is no way to export that information. Using PowerCLI on the other hand you can consolidate the above two methods into one view and have it exportable. The quickest and easier way to get started is with Get-VIPermission once connected to a vCenter in PowerCLI.
Get-VIPermission | Format-Table -AutoSize
Get-VIPermission in its default form gives you a quick overview of all Principals / Users defined with explicit permissions along with their Role, whether it’s a group, and if it’s set to propagate down the tree . Ideally you’ll only have a few groups listed here and nothing else. Unlike myself, where I had a large amount of individual users explicitly listed on many different objects.
When using Format-Table we loss a little information on the screen. Namely, we can’t see on what objects these permissions are set on. So we can work with the Get-VIPermission cmdlet to expand it out a little further.
Get-VIPermission | sort | Format-Table Entity, EntityID, Role, Principal -AutoSize
The two extra values we are looking for here are Entity and EntityID. In most cases Entity will aid in identifying the vCenter object that has the explicit permissions set on it so you can review. The Entity could be a Virtual Machine, a Cluster, or a Datastore. In some cases, though, you will find the Entity is blank.
Again, in my case I had a lot of permissions with a blank Entity. Using EntityID I could see that the objects appeared to be networking related. So in this case we need to get a little more creative with the querying of the SDK APIs using Get-View.
Get-VIPermission | sort | ft @{N=”ObjectName”;E={(get-view -Id $_.EntityID).name}}, Entity, EntityID, Role, Principal -AutoSize
This now gets us 95% of the way there. We use Get-View using the EntityID as the Get-View ID to find the actual name of the vCenter object for that missing Entity value. In the case of the networking objects we will now get the exact names of the networking switches.
Putting it all together. In this last part I turn the one liner into a little script, make sure the correct snap-in is loaded, make it a little easier to read, and have it output to a CSV file that can be used to audit and review at a later stage.
# Import Snap-in
if ((Get-PSSnapin | where {$_.Name -ilike "Vmware*Core"}).Name -ine "VMware.VimAutomation.Core")
{
Write-Host "Loading PS Snap-in: VMware VimAutomation Core"
Add-PSSnapin VMware.VimAutomation.Core -ErrorAction SilentlyContinue
}
$Date = (get-date).tostring("yyyyMMddHHmm")
$result = Get-VIPermission | sort-object -Property Principal | Select @{N="ObjectName";E={(get-view -Id $_.EntityID).name}}, EntityID, Role, IsGroup, Principal
$result | Export-CSV -Path "$pwd\vCenter_PermissionAudit-$date.csv" -NoTypeInformation -UseCulture
In the above script the results are outputted to a CSV file appended with the date. The benefit of doing this is you can schedule it to run and now have a history of the state of permissions over time. Simple as it is, I think it’s really handy.
In the next post I will look at creating a basic Alarm in vCenter that will trigger when a permission is modified on an object.