k3s

k3s is a fully conformant Kubernetes distribution, so the StackRadar scanner runs on it unchanged. The scanner is a single Deployment with modest resource requests (50m CPU, 512Mi memory), which fits comfortably on the small nodes k3s is usually chosen for. It needs outbound HTTPS to api.stackradar.io and the ability to pull your workloads’ images.

Prerequisites

• A running k3s server. Single-node is fine.
• Root or sudo on the server node, or a copy of its kubeconfig.
• Helm 3.8+ and kubectl.
• A free StackRadar account.

1. Point kubectl at your k3s cluster

   bash

   # On the k3s server node:
   export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
   kubectl get nodes
   
   # From another machine, copy the file and replace 127.0.0.1 with the server address:
   scp root@<server>:/etc/rancher/k3s/k3s.yaml ~/.kube/k3s.yaml
   sed -i 's/127.0.0.1/<server-ip>/' ~/.kube/k3s.yaml
   export KUBECONFIG=~/.kube/k3s.yaml

   k3s writes its kubeconfig to /etc/rancher/k3s/k3s.yaml, readable by root only by default. Start k3s with --write-kubeconfig-mode 644 if you want it readable by a normal user.

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

   bash

   helm 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_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. SBOMs for running workloads follow within a few minutes. If the cluster never connects, see Troubleshooting.

k3s notes

• Architecture: the scanner image is published for amd64 and arm64, so it runs on ARM single-board computers and Ampere or Graviton nodes without changes.
• Private registries configured in /etc/rancher/k3s/registries.yaml apply to the kubelet only. The scanner pulls images itself, so a registry that needs credentials also needs a pull Secret on the pods or a dockerConfigSecret on the scanner — see the private-registry guide.
• Air-gapped k3s installs need the chart and the scanner image mirrored and the one API endpoint allowed; the restricted-network guide covers it.
• Resource pressure on a single small node: the chart sets ephemeral-storage requests for the image scratch space. On a node with a small disk, lower watcher.scratchSizeLimit in the chart values rather than removing the limit.

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. See architecture & data flow for what runs where and exactly what data leaves the cluster.