Red Hat OpenShift

OpenShift is conformant Kubernetes with stricter admission defaults. The scanner runs on it, but the chart’s default security context pins a fixed UID (65534), and OpenShift’s restricted-v2 Security Context Constraint expects pods to accept a UID from the project’s assigned range instead. The install below unsets the fixed IDs so the SCC assigns them.

Prerequisites

• An OpenShift 4.x cluster and the oc CLI logged in with rights to create a project.
• Helm 3.8+ (oc does not replace it for OCI chart installs).
• Helm 3.8+ and kubectl.
• A free StackRadar account.

1. Point kubectl at your OpenShift cluster

   bash

   oc login --server=https://api.<cluster-domain>:6443
   oc new-project stackradar
   kubectl get nodes

2. Install the scanner

   Do not grant the scanner the anyuid or privileged SCC to work around admission errors. It does not need root; unsetting the fixed UID is the correct fix.

   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.

OpenShift notes

• Security context: append --set podSecurityContext.runAsUser=null --set podSecurityContext.runAsGroup=null --set podSecurityContext.fsGroup=null to the install command so the restricted-v2 SCC assigns a UID from the project range. The remaining defaults (runAsNonRoot, read-only root filesystem, dropped capabilities, RuntimeDefault seccomp) are what restricted-v2 requires.
• This override is derived from the chart’s values and OpenShift’s documented SCC behaviour; it has not yet been verified end to end on an OpenShift cluster by us. If the pod is rejected at admission, oc get events -n stackradar shows which SCC field failed — send it to us and we will fix the guide.
• Internal registry: images built by OpenShift live in image-registry.openshift-image-registry.svc:5000 and pods pull them with a ServiceAccount-linked Secret that is not listed under imagePullSecrets. The scanner cannot inherit that, so give it a dockerConfigSecret with a registry token (oc registry login creates one) — see the private-registry guide.
• Namespace vs project: helm install --create-namespace works, but oc new-project first is the OpenShift-native way and sets up the project’s UID range that the SCC uses.

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.