> ## Content Index > Fetch the complete content index at: https://www.mohammadsiddiqui.com/llms.txt > Use this file to discover other available public pages before exploring further. # What a Bank Would Ask Before Installing the vCommunity Management Pack - URL: https://www.mohammadsiddiqui.com/what-a-bank-would-ask-before-installing-the-vcommunity-management-pack/ - Published: 2026-10-18T21:33:56.000Z - Updated: 2026-10-18T21:37:16.000Z - Description: A community Management Pack for VCF Operations that is better engineered than most vendor material, and the four things worth checking before it goes near a regulated estate. - Author: Mohammad Siddiqui - Tags: architecture, operations, security Somebody sent me the [vCommunity Management Pack](https://github.com/vmbro/VCF-Operations-vCommunity?ref=mohammadsiddiqui.com) this week and asked whether it was worth looking at. It is, and more than I expected. But the question I kept turning over was a different one, because it is the question I would actually be asked in a bank: not "is this good", but "can we put it in". Those have different answers here, so this covers both. The pack is by Onur Yuzseven, with dashboards, super metrics and a large amount of recent work from Iwan Rahabok. It is built on Broadcom’s VCF Operations Integration SDK in Python, and it does not replace the vCenter adapter. It enriches it: everything collected is published onto the existing vCenter objects under a `vCommunity|` prefix. VCF Operations 8.18 or higher, vCenter 8 or higher including VCF 9.x, running on a Cloud Proxy. ## The part that impressed me I went in expecting a collection script with some dashboards attached. It is not that. The collection side does what the README says: ESXi advanced system settings, ESXi packages, VM advanced parameters, VM options, all driven by XML you can edit so it reads your own config standard, plus agentless Windows service and event log collection through GuestAPI. Useful, and covered well enough elsewhere. The part worth your attention is the derived metrics, because somebody has thought hard about how a metric should behave when the data underneath it is bad. Take Operational Availability. It replaces the stock super metrics for host and cluster availability and fixes errors in their formulas, which is already more than most community content attempts. Then the documentation lists its own limitations, and one of them reads: a cluster with no HA host failover level is treated as N+0, so the cluster value is lower than real availability, never higher. A collection failure can therefore cause a false alarm, but never false assurance. The sentence that tells you who wrote this That is the correct way round, and stating it out loud is rarer than it should be. The same document explains that a stat whose latest value is more than ten minutes old is treated as no data rather than reported as current, and that if VCF Operations returns nothing for any host in a cycle, the pack publishes nothing rather than zero percent across the estate. Anyone who has watched a monitoring platform declare a healthy estate dead at 3am because one API call timed out will recognise what is being prevented. Daily Cluster Check has the same character. It sets a Close for Business flag per cluster on a configurable window, derived from capacity utilisation, cluster performance and cluster risk, with the window arithmetic specified properly so every hour is covered exactly once. Underneath there are roughly 8,100 lines of Python, fifteen test files with fakes, a PowerShell harness that validates the installed build against a live instance read-only, twenty-two pages of documentation, and a bulk CSV importer for onboarding many vCenters. The account requirements are least-privilege by default: vCenter Read-only with Propagate to children, plus `Host.Configuration.ImageConfiguration` for VIB packages and install date. Guest OS, baseline Any standard non-admin domain or local account. Service status and OS information are readable without extra rights. Guest OS, event logs Adds membership of the local **Event Log Readers** group, which grants Security log access without full admin. Explicitly warned against Using a local Administrator account for the guest credential. That is a better security posture than plenty of commercial software ships with. ## Four things to check before it goes in ### 1\. Certificate validation is off, and you cannot turn it on In `Management Pack/app/adapter.py`, the `SmartConnect` call passes `disableSslCertValidation=True`. It is hardcoded. There is no adapter instance parameter controlling it and nothing in the describe schema exposes it. That is the pack’s primary control plane connection, carrying the vCenter service account credentials, and the certificate on the other end is never checked. In an APRA-regulated estate you will be asked about it during the CPS 234 control assessment, and the honest answer today is that it cannot be configured. It is a small fix. An adapter parameter defaulting to secure, with the current behaviour available for labs, would close it. ### 2\. The guest collection path, which deserves separating Nine `requests` calls in the Windows collection code pass `verify=False`. To be fair to the authors, those URLs come from `InitiateFileTransferToGuest` and point at the ESXi host, where a self-signed certificate is the normal case, and disabling verification there is the conventional pattern across VMware tooling rather than a careless choice. Thumbprint pinning would be better. It is not the same severity as the vCenter connection. What I would actually raise at a change advisory board is the mechanism. The pack writes a file into the guest and then calls `ProcessManager.StartProgram` to run PowerShell inside it. Even under a standard non-admin account, that is a remote execution path into every monitored Windows VM driven by one centrally held credential. Nothing about it is hidden and the documentation is straight about it. But it is a capability a security team wants named rather than discovered, and it is why I would scope guest collection to a defined subset instead of switching it on fleet-wide. ### 3\. The supply chain, which nobody mentions Every Cloud Proxy needs HTTPS access to `ghcr.io` to pull the adapter container image, and it re-pulls after every upgrade. In a locked-down environment that is a firewall change and a standing third-party dependency on GitHub Container Registry for a component sitting next to vCenter. There is a documented answer to this The project has thought about it: there is a dark site installation path using a private registry. Use it. In a bank it is the only version of this I would propose. ### 4\. The licence, which is narrower than it looks The LICENSE file is [PolyForm Noncommercial 1.0.0](https://polyformproject.org/licenses/noncommercial/1.0.0?ref=mohammadsiddiqui.com). Not Apache, not MIT, not an OSI-approved open source licence at all. PolyForm Noncommercial permits personal use, research, experiment, hobby and study, and separately permits use by charities, educational institutions, public research organisations, public safety and health organisations, environmental organisations and government institutions. A commercial bank, insurer or telco is none of those. Worth reading the LICENSE file yourself I am not a lawyer and none of this is advice. The practical point is simply that the terms are narrower than the word “free” suggests to most engineers, so if you are at a commercial enterprise it is worth putting the file in front of whoever answers that question for you, early rather than after the design work. There is also a notice obligation that travels with any copy you distribute internally. None of that is a criticism of the choice. It is the author’s work and the terms are his to set. But there are four ways this could land, and only one of them is the status quo, so they are worth laying out. PolyForm Internal Use 1.0.0 Nearest fit if the intent is "use it, do not sell it", and the smallest change, since it is the same licence family. Permits internal use by any organisation including commercial ones, and prohibits providing it to others as a product or service. Apache 2.0 The option if reach matters more than protection. Worth noting that the Aria Operations Integration SDK this is built on is itself Apache 2.0, so it would put the pack in step with its own foundation. The cost is real: anyone could fork it into a commercial product. An additional use grant Cheapest change available. Keep the licence and add a paragraph permitting internal use including commercially, while prohibiting redistribution and resale. Same intent, ambiguity removed, nothing relicensed. Leave it, and say so clearly Entirely legitimate. It needs a line near the top of the README stating that commercial production use is not permitted, so people evaluate it on that basis rather than discovering it at the procurement gate. One practical complication whichever way it goes. CONTRIBUTING invites contributions and promises that contributors get listed once their changes are approved, so if anyone else now holds copyright in the repository, a relicense would normally need their agreement. The additional use grant avoids most of that, which is another argument in its favour. ## How I would actually deploy it First environment Non-production, one vCenter, pinned to a specific release rather than tracking main. The fork I looked at had a commit land the same morning, which is a good sign about maintenance and a poor basis for a production baseline. Guest collection Off at first. Get vCenter-side collection stable and measure what it costs in VCF Operations before adding anything. When you enable it A named subset of machines, a dedicated non-admin account, and Event Log Readers only where event logs are genuinely needed. Registry Private registry via the dark site path rather than egress to ghcr.io from every proxy. Accounts Separate service accounts for vCenter and guest. Neither reused from anything else. Before any alert Read the Known Limitations section on each metric. The authors wrote them properly. It would be a waste to skip them and then be surprised by a cluster that legitimately has no availability value. Licensing, in parallel Put the LICENSE file in front of whoever answers that question in your organisation. Not a blocker to evaluating, but better answered early than late. ## What I would change If I could ask for only one change, it would be that one: make certificate validation a configurable parameter, defaulting to on. Everything else on my list is a deployment decision rather than a defect, and the licence is a choice the author is entitled to make. But a hardcoded `disableSslCertValidation=True` is the single item that turns "we need to configure this carefully" into "we cannot use this as shipped", and it is a couple of hours of work. ### Where I would take it next, if it were mine Tagged releases and a changelog The single thing that would most help a regulated customer. The current guidance is to keep registry access open so upgrades are easy, which is the opposite of what a change-controlled environment needs. Tagged releases with notes let people pin a version, test it, and upgrade on their own schedule. Configurable TLS verification A parameter defaulting to secure, with today’s behaviour still available for labs. This is the change that moves the pack from "configure it carefully" to "deployable as shipped". Pin certificates rather than skip them On the guest file transfer path, pinning against the host thumbprint would be better than disabling verification outright, and the vSphere APIs already hand you the thumbprint to do it. Guest collection as its own component It carries a different risk profile from everything else here: one credential with reach into every Windows VM, and a PowerShell execution path. Packaging it separately would let a customer adopt the vCenter-side collection without triggering the conversation the guest side triggers. Numbers for the load warning The README warns about the cost of monitoring hundreds of Windows machines, which is honest. There are no figures. Measurements at a few VM counts would turn a warning into something a capacity planner can actually use. Name the canonical repository There is this repository, the Content repository referenced in the badges, and an active fork that is currently ahead. Anyone standing it up in production has to guess which to track. A stated security reporting path SUPPORT.md covers questions well. A short SECURITY.md saying where to send a vulnerability report and what response to expect is worth having before somebody needs it rather than after. I have raised the licence question with the maintainers directly rather than only writing about it here, in [discussion #96](https://github.com/vmbro/VCF-Operations-vCommunity/discussions/96?ref=mohammadsiddiqui.com), along with [#97](https://github.com/vmbro/VCF-Operations-vCommunity/discussions/97?ref=mohammadsiddiqui.com) on running the pack under change control. At the time of publishing neither has a reply. If that changes I will update this post rather than leave it standing on my reading alone. ## Sources - [vmbro/VCF-Operations-vCommunity](https://github.com/vmbro/VCF-Operations-vCommunity?ref=mohammadsiddiqui.com), and Iwan Rahabok’s fork - [PolyForm Noncommercial License 1.0.0](https://polyformproject.org/licenses/noncommercial/1.0.0?ref=mohammadsiddiqui.com) - Findings are from reading the repository as it stood on 15 October 2026\. Line references may move. *Views here are my own. I no longer work for Broadcom, and this is written from public source code and documentation. I have no affiliation with the project.*