Documentation menu

Amazon EKS

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

Amazon EKS clusters work with StackRadar out of the box: the scanner is a normal Kubernetes workload installed with Helm, needs no AWS IAM roles, no IRSA setup, and no changes to your node groups. The only external dependency is outbound HTTPS to api.stackradar.io. Scanning images that live in a private ECR repository is the one case that needs registry credentials — see the private-registry guide.

Prerequisites

  1. Point kubectl at your EKS cluster

    bash
    aws eks update-kubeconfig --region <region> --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.

EKS networking notes

The scanner needs to reach api.stackradar.io on port 443. What that means depends on how your VPC is set up:

  • Nodes in public subnets — no extra configuration needed.
  • Nodes in private subnets — egress must go through a NAT gateway or an egress proxy. This is the standard EKS private-subnet pattern; if your workloads can pull public container images, the scanner can reach the API too.
  • Egress filtering — if you restrict outbound traffic with security groups, a firewall, or an egress proxy, allow HTTPS to api.stackradar.io. It's the single endpoint used for SBOM uploads and heartbeats.

Scanning images from a private ECR repository? The scanner pulls each image itself, so it needs ECR credentials of its own. It reuses the imagePullSecrets your pods already declare, but it cannot use the node IAM role 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.

On ECR, dockerConfigSecret has a catch: the registry password is a 12-hour token, so a static Secret needs a refresh job of your own. The cloud-native alternative is IRSA — bind an IAM role to the scanner's ServiceAccount via serviceAccount.annotations (the eks.amazonaws.com/role-arn annotation) and AWS injects short-lived credentials with nothing static 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 a cluster without any 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. See architecture & data flow for what runs where and exactly what data leaves the cluster.

Next steps