The EU Cyber Resilience Act’s 24-hour reporting duty starts 11 September 2026. What it actually requires
Documentation menu

RKE2 / Rancher

Install the StackRadar scanner on RKE2 or any Rancher-managed cluster: kubeconfig locations, the Rancher install path, CIS-hardened profiles, what to expect.

RKE2 is SUSE Rancher’s security-focused distribution and is fully conformant, so the scanner installs with the standard Helm chart. If your clusters are managed by Rancher, you can install through Rancher’s UI or with a kubeconfig downloaded from it; the result is the same Deployment either way.

Prerequisites

  • An RKE2 cluster, or any cluster registered in Rancher.
  • A kubeconfig — from the RKE2 server node or downloaded from the Rancher UI.
  • Helm 3.8+ and kubectl.
  • A free StackRadar account.
  1. Point kubectl at your RKE2 / Rancher cluster

    bash
    # On the RKE2 server node:
    export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
    export PATH=$PATH:/var/lib/rancher/rke2/bin
    kubectl get nodes
    
    # Or download the kubeconfig from Rancher (cluster → ⋮ → Download KubeConfig):
    export KUBECONFIG=~/Downloads/<cluster>.yaml
    kubectl get nodes

    A Rancher-downloaded kubeconfig routes through the Rancher server. That is fine for installing; the scanner itself talks to the in-cluster API and never depends on Rancher being reachable.

  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.

RKE2 and Rancher notes

  • CIS-hardened profiles (profile: cis) enforce Pod Security Admission at the restricted level. The scanner’s defaults — non-root, read-only root filesystem, no capabilities, RuntimeDefault seccomp — satisfy it, so no exemption is needed.
  • Rancher’s built-in registry mirrors and the registries.yaml file apply to the kubelet. The scanner pulls images with its own credentials, so private registries still need a pull Secret on the pods or a dockerConfigSecret on the scanner.
  • Installing from the Rancher UI: add the OCI chart through Apps → Repositories (type OCI) and install it with the API key and cluster ID as values. Each Rancher-managed cluster gets its own cluster-scoped key.
  • RKE2’s default NetworkPolicy-capable CNI (Canal or Cilium) will enforce the chart’s optional egress policy if you enable it; see the restricted-network guide before turning it on.

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

Next steps