Manage cnspec Providers
Learn how cnspec providers work, when to manage them yourself, and how to install, update, and remove them.
cnspec scans dozens of platforms, from AWS to Windows hosts. The code that knows how to talk to a given platform lives in a provider, and providers are loaded on demand: cnspec ships with no providers installed, and downloads each one the first time you need it.
How automatic provider management works
Suppose you install cnspec on a Linux workstation. No providers are installed yet.
- You run
cnspec scan local. cnspec needs theosprovider, downloads it, then runs the scan. Theosprovider stays on disk for next time. - You run
cnspec shell aws. cnspec needs theawsprovider, downloads it, opens the shell.
For most users this just works and there's nothing to manage. The exceptions are:
- Containers, where the provider download repeats every time the container starts.
- Read-only hosts, where cnspec can't write the provider to disk.
- Air-gapped hosts, where cnspec can't reach
releases.mondoo.com.
The next three sections walk through each.
Containers
By default, every fresh container that runs a cnspec command re-downloads providers, which slows down scans and burns network. To avoid that, do one of the following:
- Bake providers into the image. See Install a provider manually below.
- Disable auto-update so cnspec uses whatever's pre-installed. See Turn off provider auto-update.
Read-only hosts
If cnspec can't write to the host, it can't download or update providers either. Install the providers you need ahead of time and turn off auto-update so cnspec doesn't try to fetch updates and warn on every command.
In a read-only environment, you're responsible for keeping installed providers current.
Air-gapped hosts
In air-gapped networks, cnspec can't reach releases.mondoo.com to fetch providers. Download the providers you need on a connected machine, copy them across, and install them from the file. Then disable auto-update so cnspec stops trying to fetch updates.
In an air-gapped environment, you're responsible for keeping installed providers current.
Turn off provider auto-update
By default, every cnspec command checks for and installs the latest version of the provider it needs (if it isn't already installed). Disable this when you want cnspec to use only what you've already installed.
For all commands
Set auto_update: false in the cnspec configuration file. The file location depends on whether you want the setting to apply system-wide or just to one user:
- Linux, all users:
/etc/opt/mondoo/mondoo.yml - macOS, all users:
/Library/Mondoo/etc/mondoo.yml - Linux and macOS, single user:
~/.config/mondoo/mondoo.yml - Windows, all users:
C:\ProgramData\Mondoo\mondoo.yml - Windows, single user:
C:\Users\{username}\.config\mondoo\mondoo.yml
auto_update: falseThe configuration key uses an underscore (auto_update), while the command line flag uses a
hyphen (--auto-update). Writing auto-update in the file has no effect. For every setting the
file accepts, read The cnspec configuration file.
When auto-update is off, check releases.mondoo.com/providers/ periodically and update providers
manually.
For a single command
Pass --auto-update=false to skip the check just once:
cnspec scan --auto-update=falseThe flag overrides the auto_update setting in mondoo.yml.
Available providers
You can browse and download every provider at releases.mondoo.com/providers/. Past versions are kept indefinitely.
| Provider | Target |
|---|---|
activedirectory | Active Directory domains |
ai | Model Context Protocol (MCP) servers |
alicloud | Alibaba Cloud accounts |
ansible | Ansible playbooks and projects |
arista | Arista EOS network devices |
artifactory | JFrog Artifactory instances |
atlassian | Atlassian Cloud (Jira, Confluence, Bitbucket) |
auth0 | Auth0 tenants |
aws | Amazon Web Services accounts and resources |
azure | Microsoft Azure subscriptions |
bicep | Azure Bicep files and ARM templates |
bigip | F5 BIG-IP devices |
bitwarden | Bitwarden organizations |
cassandra | Apache Cassandra clusters |
checkpoint | Check Point Security Management servers |
claude | Claude AI platform accounts |
clickhousecloud | ClickHouse Cloud organizations |
clickhousedb | ClickHouse servers |
cloudflare | Cloudflare accounts |
cloudformation | AWS CloudFormation and SAM templates |
databricks | Databricks accounts and workspaces |
datadog | Datadog accounts |
db2 | IBM Db2 databases |
depsdev | deps.dev open source package metadata |
digitalocean | DigitalOcean accounts |
dropbox | Dropbox Business teams |
elasticsearch | Elasticsearch clusters |
equinix | Equinix Metal organizations and projects |
fortios | Fortinet FortiOS devices |
gcp | Google Cloud projects and folders |
github | GitHub organizations and repositories |
gitlab | GitLab groups and projects |
google-workspace | Google Workspace accounts |
grafana | Grafana organizations |
hcp | HashiCorp Cloud Platform organizations |
helm | Helm charts |
hetzner | Hetzner Cloud projects |
huggingface | Hugging Face models, datasets, and spaces |
ipinfo | ipinfo.io address lookups |
ipmi | Intelligent Platform Management Interface (IPMI) endpoints |
iru | Iru (formerly Kandji) tenants |
jamf | Jamf Pro accounts |
jumpcloud | JumpCloud organizations |
junos | Juniper Junos OS devices |
k8s | Kubernetes clusters and manifests |
keycloak | Keycloak servers |
kustomize | Kustomize overlays |
mikrotik | MikroTik RouterOS devices |
mistral | Mistral AI workspaces |
mondoo | Mondoo Platform spaces and assets |
mongo | Self-hosted MongoDB servers |
mongodbatlas | MongoDB Atlas organizations and projects |
ms365 | Microsoft 365 tenants |
mssql | Microsoft SQL Server instances |
mysqldb | MySQL and MariaDB servers |
neon | Neon organizations and accounts |
netlify | Netlify accounts |
network | DNS, TLS, and HTTP for hosts and domains |
networkdevices | Cisco IOS and NX-OS devices |
networkdiscovery | Subdomain enumeration |
nextdns | NextDNS accounts |
nmap | Nmap host and network scans |
nutanix | Nutanix Prism Central instances |
oci | Oracle Cloud Infrastructure tenancies |
okta | Okta organizations |
ollama | Ollama instances |
opcua | OPC UA devices |
openai | OpenAI accounts |
opensearch | OpenSearch clusters |
openstack | OpenStack projects |
oracledb | Oracle Database instances |
os | Linux, macOS, Windows, BSD, AIX hosts and containers |
panos | Palo Alto Networks PAN-OS devices |
portainer | Portainer instances |
postgresdb | PostgreSQL servers |
proxmox | Proxmox VE hypervisors |
redfish | Redfish management controllers (BMCs) |
redisdb | Redis and Valkey servers |
shodan | Shodan host and domain lookups |
slack | Slack workspaces |
snowflake | Snowflake accounts |
stackit | STACKIT projects |
tailscale | Tailscale tailnets |
terraform | Terraform HCL, plans, and state |
together | Together AI accounts |
unifi | Ubiquiti UniFi controllers |
vcd | VMware Cloud Director |
vercel | Vercel accounts |
vllm | vLLM inference servers |
vsphere | VMware vSphere |
weaviate | Weaviate vector databases |
yara | YARA rule scans |
zoom | Zoom accounts |
To list what's installed locally:
cnspec providersFor all providers subcommands, run cnspec providers -h.
Install a provider manually
To install the latest version of a provider:
cnspec providers install NAMEFor example:
cnspec providers install k8sTo install from a downloaded archive:
cnspec providers install -f providers/os/dist/os.tar.xzTo install from a URL:
cnspec providers install --url https://releases.mondoo.com/providers/os/9.0.7/os_9.0.7_linux_arm.tar.xzFor all flags, run cnspec providers install -h.
Update providers manually
To update every installed provider to its latest version:
cnspec providers updateTo update a single provider:
cnspec providers update vsphereRemove a provider
cnspec providers delete terraform