Skip to main content

SBOM for AWS ECR

Gain visibility into the container images stored in your Amazon Elastic Container Registry (ECR) and the software packages they include. The SBOM for AWS ECR integration assumes an IAM role in your AWS account, discovers repositories by tag, and scans your most recent images for software components and known vulnerabilities, enabling you to query, monitor, and alert on changes in your software supply chain.

Installation​

For this integration, you will need an AWS account with one or more images stored in Amazon Elastic Container Registry (ECR), and an IAM role that your JupiterOne Collector can assume to read from your registry. The integration authenticates by assuming this role with an auto-generated External ID, discovers repositories by tag, and scans the most recent images in each matching repository for SBOM (Software Bill of Materials) ingestion.

Requires a Collector

SBOM for AWS ECR runs on a JupiterOne Collector — it does not run on JupiterOne-managed infrastructure. The Collector pulls and unpacks your image layers and scans them locally for packages and vulnerabilities, so it needs the compute, disk, and network reach to your registry. You must have a Collector enrolled before configuring this integration, and the Collector is the identity that assumes the IAM role described below.

Set permissions in AWS​

Create an IAM role in the AWS account that hosts your ECR registry, and configure its trust policy to allow your Collector's AWS identity to assume it, using the External ID that is auto-generated when you create the integration instance (see below).

Because this integration runs on a Collector, the role is assumed by the AWS identity the Collector process runs as — not by any JupiterOne-managed AWS account. Set the trust policy Principal to your Collector's identity:

  • If your Collector runs on EC2, use its instance-profile role ARN. When the Collector runs in the same AWS account as the ECR registry, you may trust the account root (arn:aws:iam::<account-id>:root) instead.
  • If your Collector runs elsewhere with configured AWS credentials, use the ARN of that principal.

Do not add the JupiterOne AWS account IDs from the managed AWS integration's CloudFormation template — those apply to the managed AWS integration, not to this Collector-run integration. Always keep the sts:ExternalId condition.

Kubernetes Collector: give the job pod an AWS identity first

On a Kubernetes-based Collector, the integration runs in a job pod that the operator spawns — and that pod is the identity assuming your role. A job pod with no AWS credentials cannot sign the sts:AssumeRole call, and the job fails with a Configuration failure.

Running SBOM for AWS ECR on a Kubernetes Collector requires the operator chart jupiterone-integration-operator 1.4.0+ (operator v0.4.0+). Upgrade the chart before configuring the integration. The chart provisions a dedicated ServiceAccount for integration job pods and annotates it for IRSA, so only those pods receive the AWS identity; this requires an IAM OIDC provider on the cluster.

  1. Create a base role whose trust policy federates that provider for the job ServiceAccount (jupiterone-integration-job in the runner's namespace):

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": { "Federated": "arn:aws:iam::<account-id>:oidc-provider/oidc.eks.<region>.amazonaws.com/id/<oidc-id>" },
          "Action": "sts:AssumeRoleWithWebIdentity",
          "Condition": {
            "StringEquals": {
              "oidc.eks.<region>.amazonaws.com/id/<oidc-id>:sub": "system:serviceaccount:jupiterone:jupiterone-integration-job",
              "oidc.eks.<region>.amazonaws.com/id/<oidc-id>:aud": "sts.amazonaws.com"
            }
          }
        }
      ]
    }

  2. Give that base role permission to sts:AssumeRole the ECR role below, then enable and annotate the job ServiceAccount in the chart values:

    integration:
      jobServiceAccount:
        create: true
        annotations:
          eks.amazonaws.com/role-arn: arn:aws:iam::<account-id>:role/<collector-base-role>

The chart creates the ServiceAccount and annotates it. The operator reconciles the IntegrationInstance and runs each integration's job pod under that ServiceAccount, so the pod picks up the IRSA annotation and its AWS identity. Set the ECR role's trust Principal to this base role ARN.

This base role lives in the AWS account where your EKS cluster runs. When the ECR registry is in that same account, the ECR role's trust Principal is simply this base role's ARN; when the registry is in a different account, the ECR role (created in the registry's account) trusts the base role's ARN cross-account. Either way the Principal is your collector's base role — not any JupiterOne-managed AWS account.

For example, when the Collector runs in the same account as the registry:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::<account-id>:root" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "<auto-generated-external-id>" }
      }
    }
  ]
}

Attach a policy granting the following read-only Amazon ECR permissions:

  • ecr:GetAuthorizationToken
  • ecr:DescribeRepositories
  • ecr:ListTagsForResource
  • ecr:DescribeImages
  • ecr:BatchCheckLayerAvailability
  • ecr:GetDownloadUrlForLayer
  • ecr:BatchGetImage

ecr:GetAuthorizationToken, ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer, and ecr:BatchGetImage allow the integration to authenticate to the registry and pull image layers for scanning. ecr:DescribeRepositories and ecr:ListTagsForResource are used to discover repositories by tag, and ecr:DescribeImages to select the most recent images per repository.

Configuration in JupiterOne​

To install the SBOM for AWS ECR integration in JupiterOne, navigate to the Integrations tab and select SBOM for AWS ECR. Click New Instance to begin configuring your integration.

Creating an instance requires the following:

  • Registry – The URL of your ECR registry, such as <account-id>.dkr.ecr.<region>.amazonaws.com for a private registry or public.ecr.aws/<namespace> for a public registry.
  • Role ARN – The ARN of the IAM role the Collector assumes to authenticate with AWS.
  • External ID – Auto-generated by JupiterOne. Use this value when configuring the trust policy of the IAM role. You may change it, but doing so is against Amazon's security recommendations.
  • Region – (Optional) The AWS region where the registry is located. Defaults to us-east-1 and is not inferred from the Registry URL — if your registry is in any other region, set this explicitly or the integration will silently target us-east-1 and fail to reach your repositories.

Data filters​

  • Tag – Filter which repositories to ingest SBOMs from using AWS resource tags. Use the format tag-key:tag-value (for example, environment:production), or specify only the tag key to match any value (for example, environment). Only repositories carrying a matching tag are processed.
  • Images to Scan – The number of most recent images to scan per repository (1, 2, or 3). Defaults to 1.

If your registry is served behind an internal or self-signed certificate, you can optionally provide a Certificate Authority Certificate (PEM format, full CA chain) under TLS / Certificate Settings to verify the TLS connection to the registry.

Click Create once all required values are provided to finalize the integration.

Next steps​

Now that your integration instance has been configured, it will begin running on the polling interval you provided, populating data within JupiterOne. Continue on to our Instance management guide to learn more about working with and editing integration instances.