Granting Service Account Access to Pull the DataHub Executor Docker Image – DataHub Customer Support Portal

Area: Deployment Issues

Sub-Area: Remote Executor Image Registry Access

Issue

When deploying the DataHub Remote Executor, your CI/CD pipeline or Kubernetes nodes may fail to pull the datahub-executor container image from the DataHub private registry. This typically occurs when a new service account (GCP) or AWS IAM account is introduced — for example, when rotating credentials, migrating to a new CI runner identity, or setting up a new environment — and the new principal has not yet been granted read access to the DataHub image registry. The pull fails with an authorization or access-denied error, blocking executor deployment entirely.

Error Messages

ERROR: (gcloud.artifacts.docker.images.list) PERMISSION_DENIED: Permission "artifactregistry.repositories.downloadArtifacts" denied
denied: Your authorization token does not have the required permissions
Error response from daemon: pull access denied for 795586375822.dkr.ecr.us-west-2.amazonaws.com/datahub-executor
ImagePullBackOff / ErrImagePull on Kubernetes pods running the executor

You Might Be Asking

Which registry hosts the official DataHub executor image, and what is the correct image path?
How do I request pull access for a new GCP service account or AWS IAM account?
What information does DataHub Support need to add a new principal to the allowlist?
My old service account had access but a new one does not — why does switching accounts break image pulls?
What IAM permissions does my executor role need on my own cloud account after DataHub grants access?

Solution

Step 1 — Identify the Correct Registry

Before requesting access, confirm that your deployment is pulling from the official DataHub-managed registry, not a mirror or copy in your own cloud project. The canonical image paths are:

GCP Artifact Registry (GCR): us-docker.pkg.dev/acryl-prod/datahub/datahub-executor
AWS ECR: 795586375822.dkr.ecr.us-west-2.amazonaws.com/datahub-executor (also available in us-east-1 and eu-west-1)

If your image path points to a registry in your own cloud project (e.g., a GCR path under your own GCP project ID, or your own ECR account), the image has been mirrored there and DataHub Support cannot grant access to it. In that case, your own cloud administrators must manage pull permissions for that copy.

Step 2 — Gather the Required Information

Open a support request with DataHub and provide the following:

For GCP (Artifact Registry / GCR): The full service account email address for each environment, e.g.:

serviceAccount:your-runner-prd@your-gcp-project.iam.gserviceaccount.com
serviceAccount:your-runner-tst@your-gcp-project.iam.gserviceaccount.com

For AWS (ECR): The AWS account ID or root ARN for each environment, e.g.:
```
arn:aws:iam::<dev-account-id>:root
arn:aws:iam::<prod-account-id>:root
```
The image tag or DataHub instance version you are targeting (e.g., v0.3.15.4-acryl or v2.3.0-cloud).
The exact docker pull command or Helm image reference your deployment uses, so Support can confirm the registry path.

Step 3 — DataHub Support Adds the Principal to the Allowlist

DataHub Support will update the registry resource policy to grant read-only pull access to the supplied principals:

GCP: The service account is granted roles/artifactregistry.reader on the us-docker.pkg.dev/acryl-prod/datahub repository.

AWS: The AWS account ID is added to the ECR repository policy with the following read-only actions:

ecr:GetAuthorizationToken
ecr:BatchGetImage
ecr:GetDownloadUrlForLayer
ecr:BatchCheckLayerAvailability
ecr:DescribeRepositories
ecr:DescribeImages
ecr:ListImages

DataHub Support will notify you when the change has been applied.

Step 4 — Configure Permissions on Your Side

The registry grant alone is not sufficient; the identity that performs the pull must also have the appropriate permissions in your own cloud account.

For GCP deployments:

The GCP service account performing the pull must have permission to call the Artifact Registry API. Ensure the service account has roles/artifactregistry.reader or equivalent at the project or repository level within your own GCP project.
If using Workload Identity on GKE, confirm the Kubernetes service account is bound to the GCP service account that was allowlisted.
Check that no VPC Service Controls perimeter or organization policy blocks cross-project registry access.

For AWS deployments:

The IAM role your executor runs as (e.g., the EKS node role or an IRSA role) must have an identity-based policy that permits the ECR read actions on the DataHub repository ARN:

{
  "Effect": "Allow",
  "Action": [
    "ecr:GetAuthorizationToken",
    "ecr:BatchGetImage",
    "ecr:GetDownloadUrlForLayer",
    "ecr:BatchCheckLayerAvailability"
  ],
  "Resource": [
    "arn:aws:ecr:us-west-2:795586375822:repository/datahub-executor"
  ]
}

ecr:GetAuthorizationToken must also be allowed on * (it does not support resource-level restrictions).
The AWS managed policy AmazonEC2ContainerRegistryReadOnly satisfies these requirements and is already attached to most EKS node roles.

Step 5 — Test the Pull

GCP / Docker:

# Authenticate as the service account
gcloud auth print-access-token \
  --impersonate-service-account=your-runner@your-gcp-project.iam.gserviceaccount.com \
  | docker login -u oauth2accesstoken --password-stdin https://us-docker.pkg.dev

# Pull the image
docker pull us-docker.pkg.dev/acryl-prod/datahub/datahub-executor:<version>

AWS / ECR:

# Authenticate to ECR (replace region as needed)
aws ecr get-login-password --region us-west-2 \
  | docker login --username AWS --password-stdin \
    795586375822.dkr.ecr.us-west-2.amazonaws.com

# Pull the image
docker pull 795586375822.dkr.ecr.us-west-2.amazonaws.com/datahub-executor:<version>-cloud

IAM changes may take a few minutes to propagate. If the pull fails immediately after the grant is applied, wait 2–5 minutes and retry before raising a follow-up.

Step 6 — Update Helm Values

Once pull access is confirmed, set the image reference in your datahub-executor-worker Helm chart values:

# GCP example
image:
  repository: us-docker.pkg.dev/acryl-prod/datahub/datahub-executor
  tag: "<version>"

# AWS ECR example
image:
  repository: 795586375822.dkr.ecr.us-west-2.amazonaws.com/datahub-executor
  tag: "<version>-cloud"

Additional Notes

Mirrored images: Some organizations copy the datahub-executor image into their own private registry for security or network policy reasons. If you do this, DataHub Support cannot manage pull access to your mirror — that must be handled by your own cloud or platform administrators. Your mirror-sync process will need pull access to the DataHub registry (follow the steps above for the sync identity), and your executor pods then pull from your internal copy.

Principal rotation: Whenever a service account or IAM role used to pull the executor image is rotated, renamed, or replaced, a new access request must be submitted to DataHub Support. Previously allowlisted principals are not automatically migrated to new identities. The old principal remains on the allowlist until explicitly removed.

AWS ECR regions: The DataHub ECR repository is replicated to us-west-2, us-east-1, and eu-west-1. Pull from the region geographically closest to your deployment to minimize latency and data transfer costs.

Image tags: Tags follow the pattern <datahub-version> for GCR and <datahub-version>-cloud for ECR. Confirm the correct tag for your DataHub Cloud instance version with Support before deploying.