kind (local evaluation)
Evaluate the StackRadar scanner on a local kind cluster in five minutes: create the cluster, deploy something to scan, install the chart, see ranked findings.
kind runs Kubernetes in Docker and is the fastest way to see what StackRadar shows for a real workload before installing it anywhere that matters. The scanner runs on kind unchanged; the one difference from a production cluster is where images come from.
Prerequisites
- Docker and kind installed locally.
- Helm 3.8+ and kubectl.
- A free StackRadar account.
Point kubectl at your kind (local) cluster
bashkind create cluster --name stackradar-eval kubectl get nodes # Deploy something worth scanning: kubectl create deployment demo --image=nginx:1.25 kubectl create deployment demo-py --image=python:3.11-slimThe scanner pulls images from their registry to generate SBOMs. Images loaded with kind load docker-image exist only in the node’s containerd and cannot be pulled, so they will show as scan failures. Use images that live in a registry for the evaluation.
Install the scanner
Create a cluster in the StackRadar dashboard and copy its cluster ID and cluster-scoped API key (see API keys & cluster scoping):
bashexport STACKRADAR_API_KEY=<your-api-key> export STACKRADAR_CLUSTER_ID=<your-cluster-id>Then install the scanner chart (Helm 3.8+ for the OCI method). The command pins the current release,
0.3.0— published versions are immutable, so the install is reproducible.bashhelm install stackradar-scanner \ oci://ghcr.io/lockdep/charts/stackradar-scanner \ --version 0.3.0 \ --namespace stackradar --create-namespace \ --set stackradar.apiKey=$STACKRADAR_API_KEY \ --set stackradar.clusterId=$STACKRADAR_CLUSTER_IDVerify
bashkubectl get pods --namespace stackradarOnce the pod is
Running, the scanner sends a heartbeat and the cluster shows as connected in the dashboard. SBOMs for running workloads follow within a few minutes. If the cluster never connects, see Troubleshooting.
kind notes
- A kind cluster counts as one cluster on the Free plan. Delete it from the dashboard when you are done, or keep it — the SBOMs of stopped images stay retrievable for the plan’s history window.
- kind create cluster puts the kubeconfig in ~/.kube/config and switches the context to it, so no export is needed.
- To clean up: kind delete cluster --name stackradar-eval.
Images from a private registry? The scanner pulls each image itself and reuses the imagePullSecrets your pods declare. If your nodes authenticate some other way, give the scanner a credential via dockerConfigSecret — see authenticating to a private registry. No public egress at all? Same page: restricted-network installs.
What happens after install
The scanner reports the cluster's workload inventory first — namespaces, workloads, containers, plus the Helm releases and GitOps applications that deliver them — so the dashboard shows every discovered workload and its scan coverage right away. Its first pass covers the whole cluster, not just new deploys: the initial sync lists every pod already running, and each container image is queued for scanning immediately. The scanner generates a CycloneDX SBOM per image and uploads it for matching against 900K+ OSV.dev advisories, then keeps coverage current as pods start, restart, or change — no scan schedules to configure. On kind the first SBOMs typically appear within a minute or two of the pod going Running.See architecture & data flow for what runs where and exactly what data leaves the cluster.
Next steps
- Architecture & data flowHow the StackRadar scanner works: what runs in your cluster, exactly what data leaves it, how SBOMs are matched to vulnerabilities, and where data is stored.
- TroubleshootingFixes for common StackRadar scanner issues: 401/403 API errors, a cluster that never appears in the dashboard, Helm install failures, and missing SBOMs.