Documentation menu

kind (local evaluation)

Evaluate the StackRadar scanner on a local kind cluster: create the cluster, deploy something to scan, install the chart with one Helm command, see your first findings within minutes.

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

  1. Point kubectl at your kind (local) cluster

    bash
    kind 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-slim

    The 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.

  2. 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):

    bash
    export 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.4.0 — published versions are immutable, so the install is reproducible.

    bash
    helm install stackradar-scanner \
    oci://ghcr.io/lockdep/charts/stackradar-scanner \
    --version 0.4.0 \
    --namespace stackradar --create-namespace \
    --set stackradar.apiKey=$STACKRADAR_API_KEY \
    --set stackradar.clusterId=$STACKRADAR_CLUSTER_ID

  3. Verify

    bash
    kubectl get pods --namespace stackradar

    Once the pod is Running, the scanner sends a heartbeat and the cluster shows as connected in the dashboard. Expect the first findings within minutes. If the cluster never connects, see Troubleshooting.

kind notes

  • A kind cluster counts as one cluster against your plan’s limit. 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, expect the first findings within minutes of the pod going Running.See architecture & data flow for what runs where and exactly what data leaves the cluster.

Next steps