Documentation menu

Google GKE

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

Google Kubernetes Engine clusters work with StackRadar out of the box: the scanner installs with Helm like any other workload and needs no GCP service accounts, Workload Identity bindings, or node pool changes. The only external dependency is outbound HTTPS to api.stackradar.io. Scanning images that live in a private Artifact Registry is the one case that needs registry credentials — see the private-registry guide.

Prerequisites

  1. Point kubectl at your GKE cluster

    bash
    gcloud container clusters get-credentials <cluster-name> \
    --region <region> --project <project-id>
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.

GKE networking notes

  • Public clusters — no extra configuration needed.
  • Private clusters — nodes have no public IPs, so outbound traffic to api.stackradar.io must go through Cloud NAT or an egress proxy. If your workloads can pull images from public registries, the scanner can reach the API too.
  • Egress filtering — with VPC firewall rules, VPC Service Controls, or an egress proxy in place, allow HTTPS (port 443) to api.stackradar.io. That is the single endpoint used for SBOM uploads and heartbeats.

Scanning images from a private Artifact Registry? The scanner pulls each image itself, so it needs registry credentials of its own. It reuses the imagePullSecrets your pods already declare, but it cannot use the node service account your kubelet pulls with — 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 Workload Identity — bind a GCP service account with registry read access to the scanner's ServiceAccount via serviceAccount.annotations (the iam.gke.io/gcp-service-account annotation) and GKE injects short-lived credentials with nothing to rotate. 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. New GKE node pools, spot/preemptible node churn, and autoscaling events 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