Documentation menu

Azure AKS

Continuous SBOM generation and vulnerability scanning on Azure AKS: connect kubectl, install the StackRadar Helm chart, and verify the scanner reports.

Azure Kubernetes Service clusters work with StackRadar out of the box: the scanner installs with Helm like any other workload and needs no Azure managed identities, RBAC role assignments, or node pool changes. The only external dependency is outbound HTTPS to api.stackradar.io.

Prerequisites

  1. Point kubectl at your AKS cluster

    bash
    az aks get-credentials --resource-group <resource-group> --name <cluster-name>
kubectl get nodes

  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. Expect the first findings within minutes. If the cluster never connects, see Troubleshooting.

AKS networking notes

  • Default outbound (load balancer or NAT gateway) — no extra configuration needed.
  • User-defined routing through Azure Firewall — clusters using outboundType: userDefinedRouting filter egress. Add an application rule allowing HTTPS to api.stackradar.io; it's the single endpoint used for SBOM uploads and heartbeats.
  • Private clusters — a private API server endpoint doesn't affect the scanner (it talks to the in-cluster API service), but node egress still needs a path to api.stackradar.io.

Scanning images from a private Azure Container Registry? The scanner pulls each image itself, so it needs ACR credentials of its own. It reuses the imagePullSecrets your pods already declare, but an ACR attached to the cluster with az aks update --attach-acr authenticates the kubelet, not the scanner — so if your pods carry no pull Secret, give the scanner a credential via dockerConfigSecret. See authenticating to a private registry.

The cloud-native alternative to a static credential is Azure Workload Identity — it reads a pod label as well as annotations, so it's wired up through podLabels (azure.workload.identity/use), podAnnotations, and serviceAccount.annotations (the azure.workload.identity/client-id annotation). One trap: the use label must be the string "true", so set it with --set-string — a plain --set turns it into a boolean the chart rejects. The chart wires this up, but the path is not yet verified end to end, so treat dockerConfigSecret as the fallback known to work — details and the exact command in the chart README.

Running without public egress? Same page: private registry & 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. Node image upgrades, cluster autoscaler churn, and new node pools need no reconfiguration — scanning follows pods, not infrastructure. See architecture & data flow for what runs where and exactly what data leaves the cluster.

Next steps