Vmware Harden
VMware compliance scanning (CIS, vSphere SCG, GB/T 22239, PCI-DSS) with drift detection.
- Transport
- Not stated
- Package
- —
- Registry id
- io.github.vmware-skills/vmware-harden
No install snippet on purpose. A working MCP config is a command, its arguments and an environment block — the last two are where API keys live, so this catalogue never stores them and cannot publish them. Follow the link above for the authors' own instructions.
Disclaimer: Community-maintained open-source project. Not affiliated with, endorsed by, or sponsored by VMware, Inc. or Broadcom Inc. "VMware", "vSphere", "ESXi", and "NSX" are trademarks of Broadcom. Source code is publicly auditable at github.com/vmware-skills/VMware-Harden under the MIT license.
English | 中文
AI-native VMware compliance and baseline enforcement. Sibling to the vmware-* skill family.
- Read-only against vSphere: all 8 MCP tools carry the
[READ]marker and none mutate managed VMware infrastructure;scan_targetwrites only to the local twin DB (a cache of its own observations). See Read-only by design.
GA family member (since v1.5.18)
Production-ready compliance platform with 9 built-in baselines (CIS ESXi 8.0 + 9.0, vSphere SCG v8 + v9, vSphere 9 STIG-aligned, 等保 2.0 三级, PCI-DSS 4.0, EU NIS2, BSI IT-Grundschutz) carrying 99 rules, multi-vCenter Twin, drift detection, LLM Remediation Advisor, MCP server with 8 audited tools, web dashboard, and vmware-harden doctor environment diagnostics.
Quickstart
# The collectors extra is what makes `scan` work: harden reads inventory
# through vmware-aiops / vmware-storage / vmware-nsx-security, and `uv tool
# install` gives each tool its own environment — installing them separately
# puts them where harden cannot import them from.
uv tool install "vmware-harden[collectors]"
# Reporting on an existing twin DB needs no collectors:
# uv tool install vmware-harden
# List built-in baselines
vmware-harden baseline list
# Run a scan
vmware-harden scan --target <vcenter-name> --baseline cis-vmware-esxi-8.0-subset
# Or use 等保 2.0 三级 (国内合规独家)
vmware-harden scan --target <vc> --baseline dengbao-2.0-level3-vmware
# View results
vmware-harden report
vmware-harden drift
# Generate remediation suggestions
export ANTHROPIC_API_KEY=... # optional; falls back to mock without
vmware-harden advise --all-critical
# Web dashboard
vmware-harden web --port 8080 # → http://127.0.0.1:8080
Reading a result: violations alone are not a verdict
A rule can only judge configuration that was actually gathered, and that fails
in two independent ways. A rule whose attribute no collector produces is not
executed at all. A rule that does run can still learn nothing about one
particular host, because there the value came back absent or as the N/A
sentinel — an unreachable host, an account without the privilege, a setting the
ESXi build does not have. Neither is reported as passing:
$ vmware-harden report
No violations among the checks that could be made.
16 of 20 rules could not be evaluated — no collector provides the data they
check, so their result is unknown, not compliant. 6 of 8 per-node checks could
not be made across 2 node(s): the rules ran, but the values they read were
missing on those nodes, so those nodes are unknown rather than compliant.
Not evaluated:
cis-esxi-2.1.1 no collector writes host.ntp_enabled
...
Not judged on these nodes (data missing):
cis-esxi-2.2.1 esx-02 esxi_build
...
--format json returns {"violations": [...], "coverage": {...}}, and the MCP
tools return the same coverage block, so an agent reading violations: 0
cannot conclude "compliant" on its own. Before v1.9.0 the uncollected-attribute
rules matched zero rows and were silently counted as passes; before v1.10.0 the
per-node case was, too. See RELEASE_NOTES.md.
The two lists call for different work: the first is waiting on a collector, the second on that node's reachability and the scanning account's privileges.
Offline / Air-Gapped Install (from source)
From the project's README.