Kubernetes Inventory and Vulnerability Scanning

Nanitor provides inventory and vulnerability scanning for Kubernetes workloads using a deployment-centric model. Your running Deployments, StatefulSets, and DaemonSets are imported as persistent assets in Nanitor's inventory — giving CISOs and security managers a clear overview of which applications are deployed, which are at risk, and how remediation is progressing across image updates.

Results are imported into Nanitor via an open-source tool. No cloud provider credentials or container registry access needs to be shared with Nanitor.

Why this approach?

Traditional container scanning pulls images to a central machine, scans them, and treats each image as a separate asset. This creates problems: images are ephemeral, fixing a vulnerability means deploying a new image (which creates a new asset), and you end up with a cluttered list of stale image assets instead of a clear picture of your running applications.

Nanitor takes a different approach: your running workloads (Deployments, StatefulSets, DaemonSets) are the assets. When you deploy a patched image, the workload asset is updated — not replaced — so your remediation history and health scores are preserved. This gives you a persistent, business-relevant view of your Kubernetes security posture.

About Trivy

Trivy is a widely-used open-source security scanner maintained by Aqua Security. It can scan running Kubernetes workloads and their container images for known vulnerabilities (CVEs) without needing to pull images to a separate machine — it inspects them directly using the cluster's own credentials.

Nanitor uses Trivy as the scanning engine because:

It runs in-cluster or from any machine with kubectl access — no separate infrastructure needed
It uses the cluster's own native credentials (imagePullSecrets) to access private registries — no need to share cloud provider or registry credentials with Nanitor
It supports any Kubernetes platform (AWS EKS, Google GKE, Azure AKS, self-hosted)
It provides package-level detail (which package, installed version, fixed version) for actionable remediation
It is user-managed — you control when and how often scans run, and you always have the latest scanner version with the most up-to-date vulnerability database

Nanitor provides an open-source import tool that converts Trivy's output into Nanitor's asset format and uploads it via the API. This keeps the integration simple and decoupled — if Trivy updates its output format, the tool can be updated independently of Nanitor itself.

How it works

Trivy runs against your cluster and inventories running workloads and their container images for known vulnerabilities.
The Nanitor K8s import tool converts Trivy's output and uploads it to Nanitor via the /assets/import API.
Nanitor creates a Cluster → Workload asset hierarchy with vulnerability details at the workload level.

This supports any Kubernetes cluster — AWS EKS, Google GKE, Azure AKS, or self-hosted — as long as you can run kubectl and Trivy against it.

What you get in Nanitor

Once scanning is set up, you'll see:

Kubernetes Clusters as parent assets, showing the cluster name, version, and overall health score
Kubernetes Workloads as child assets under each cluster, identified by namespace and name (e.g., finance::payment-api)
Vulnerabilities on each workload with package-level detail — which package is affected, what version is installed, and what version fixes it
Persistent tracking — when you deploy a new image version to fix a vulnerability, the workload asset is updated (not replaced), so your remediation history is preserved
Health scores and prioritization — workloads get the same health scoring and NPS prioritization as any other Nanitor asset

Prerequisites

Nanitor server version 6.8.0 or later
A Nanitor API key with write access to the target organization (see REST API)
A machine with access to the Kubernetes cluster (kubectl configured)
Python 3.8 or later

No dedicated infrastructure is required — you can run scans from any machine with kubectl access, such as a CI/CD pipeline, a bastion host, or an existing admin workstation.

Setup

1. Install Trivy

Follow the Trivy installation guide for your platform. For example:

# macOS
brew install trivy

# Ubuntu/Debian
sudo apt-get install trivy

# Or download from GitHub releases
# https://github.com/aquasecurity/trivy/releases

Verify it's working:

trivy --version

2. Install the Nanitor K8s import tool

git clone https://github.com/Nanitor/k8s-import-tool.git
cd k8s-import-tool
pip install -r requirements.txt

3. Run your first scan

Generate a Trivy Kubernetes report:

trivy k8s --report summary -f json -o trivy-report.json

This scans all workloads in the cluster accessible via your current kubectl context.

4. Preview the results (optional)

To see what will be imported without actually uploading:

python trivy-to-nanitor.py trivy-report.json --dry-run

5. Import into Nanitor

python trivy-to-nanitor.py trivy-report.json \
  --api-url https://your-nanitor-server.com/api/v1/assets/import \
  --api-key YOUR_API_KEY \
  --org-id YOUR_ORGANIZATION_ID

After import, navigate to Inventory > Assets in Nanitor and filter by Type: Kubernetes Cluster or Kubernetes Workload to see your imported assets.

6. Schedule regular scans

For continuous monitoring, set up a cron job or CI/CD pipeline step to run the scan and import on a regular schedule. For example, a daily cron job:

# /etc/cron.d/nanitor-k8s-scan
0 6 * * * /path/to/scan-and-import.sh

Where scan-and-import.sh contains:

#!/bin/bash
set -e
trivy k8s --report summary -f json -o /tmp/trivy-report.json
python /path/to/k8s-import-tool/trivy-to-nanitor.py /tmp/trivy-report.json \
  --api-url https://your-nanitor-server.com/api/v1/assets/import \
  --api-key "$NANITOR_API_KEY" \
  --org-id "$NANITOR_ORG_ID"

Vulnerability resolution

When you re-import a workload:

Vulnerabilities not included in the new import are automatically marked as resolved
Vulnerabilities included in the new import remain open or are newly created

This means that deploying a patched image and re-scanning will automatically resolve the fixed vulnerabilities in Nanitor — no manual cleanup needed.

Comparison with collector-based EKS scanning

Nanitor previously supported Kubernetes scanning through the collector for AWS EKS. The API-based approach described here replaces and improves on that model:

	API-based (recommended)	Collector-based (legacy)
Supported platforms	Any Kubernetes (EKS, GKE, AKS, self-hosted)	AWS EKS only
Asset model	Deployment-centric (persistent workloads)	Image-centric (ephemeral images)
Credentials	None shared with Nanitor	AWS and registry credentials on collector
Disk space	Minimal	Downloads container images locally
Scanner	Latest Trivy (user-managed)	Bundled older Trivy version
Remediation tracking	Preserved across image updates	Lost when new image creates new asset

Troubleshooting

Assets not appearing after import

Verify your API key has write access to the organization
Check that the organization ID is correct
Ensure Trivy produced a valid JSON report (trivy-report.json should not be empty)

Vulnerabilities not showing on workloads

Ensure Trivy is scanning with vulnerability detection enabled
Check that the workload's containers have images that Trivy can analyze

Parent-child relationship not showing

The Cluster and its Workloads can be imported in the same request — the tool handles this automatically
If importing manually, ensure parent_source_unique_id on the workload matches the cluster's source_unique_id

API reference

For advanced use cases or building custom integrations, the import uses the /assets/import API endpoint. See the Nanitor API documentation for the full specification, including the supported fields for container_platform and container_workload asset types.