Any Kubernetes cluster

The platform-agnostic installation guide: what the StackRadar scanner needs from any conformant Kubernetes cluster — k3s, kubeadm, OpenShift, Rancher, or managed cloud — plus configuration, upgrades, and uninstall.

The scanner is a standard Kubernetes workload installed with Helm — it doesn't depend on any cloud provider API, CRDs, or admission webhooks. If your distribution runs upstream Kubernetes (k3s, kubeadm, OpenShift, Rancher, VMware Tanzu, DigitalOcean, Hetzner, a homelab…), this guide applies. For EKS, GKE, and AKS there are dedicated guides with platform-specific networking notes: EKS, GKE, AKS.

What the scanner needs from a cluster

Every platform difference reduces to these four things:

Requirement	Detail
A working `kubectl` context	With permission to create a namespace and install workloads. How you obtain credentials is the main thing that varies per platform.
Helm	3.8+ for the OCI install method; older Helm 3 works with the classic repo.
Ability to pull the scanner image	From the public registry, or from your own registry if you mirror it (see restricted-network installs).
Outbound HTTPS to `api.stackradar.io`	Port 443, the single endpoint used for SBOM uploads and heartbeats. NAT, egress proxies, and firewalls are fine as long as this path exists.

A useful rule of thumb: if your workloads can pull public container images, the scanner will run and report. There are no privileged host requirements, node agents, or kernel modules involved.

1. Install

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

bash

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

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

Configuration

The two required values are stackradar.apiKey and stackradar.clusterId. Everything else has defaults; list the full set of configurable values with:

bash

helm show values oci://ghcr.io/lockdep/charts/stackradar-scanner

For anything beyond the two credentials, prefer a values file over a chain of --set flags — it can live in git (minus the key) and makes upgrades reproducible:

bash

helm upgrade --install stackradar-scanner \
    oci://ghcr.io/lockdep/charts/stackradar-scanner \
    --namespace stackradar --create-namespace \
    --set stackradar.apiKey=$STACKRADAR_API_KEY \
    --values my-values.yaml

Keep the API key out of the values file and out of git — inject it at deploy time from your CI secret store or secret manager, as above. See API keys & cluster scoping.

Upgrading

bash

helm upgrade stackradar-scanner \
    oci://ghcr.io/lockdep/charts/stackradar-scanner \
    --namespace stackradar --reuse-values

The dashboard shows each cluster's reported scanner version, so you can see at a glance which clusters are behind.

Uninstalling

bash

helm uninstall stackradar-scanner --namespace stackradar
kubectl delete namespace stackradar

Then revoke the cluster's API key in the dashboard. Already-uploaded SBOMs and scan history remain until you delete the cluster there too.

Notes for common distributions

GitOps (Argo CD / Flux) — the chart works as a normal Helm source. Supply stackradar.apiKey from a Secret-backed mechanism (e.g. a sealed or external secret) rather than committing it to the repo.
OpenShift and other policy-enforcing platforms — the scanner runs as an ordinary unprivileged workload. If your platform enforces restrictive security context or image policies, review the chart's defaults with helm template, or browse its manifests, values, and version history on Artifact Hub — the same way you vet any third-party chart.
Single-node / edge clusters (k3s, k0s, microk8s) — no special configuration; the scanner's footprint is a single small deployment, so it's reasonable to run on constrained hardware.
Clusters behind proxies or with filtered egress — see private registry & restricted-network installs.

What happens after install

The scanner watches for pods starting anywhere in the cluster, generates a CycloneDX SBOM per container image, and uploads it for matching against 300K+ OSV.dev advisories — no scan schedules to configure. See architecture & data flow for what runs where and exactly what data leaves the cluster.