✦ For everyone, free.

Practical knowledge for real and everyday life

Home

10.3.2.5 GAR Kubernetes Integration

A focused guide to GAR Kubernetes Integration, connecting core concepts with practical Docker and container operations.

GAR Kubernetes integration allows a Kubernetes cluster running on Google Kubernetes Engine (GKE) to pull images directly from Artifact Registry using the cluster's own Google Cloud service account permissions, without requiring a separately configured Kubernetes image pull secret.

How a GKE Workload Pulls From Artifact Registry

A pod specification references an Artifact Registry image directly, with the underlying node's service account permissions handling authentication transparently.

spec:
  containers:
    - name: api
      image: us-central1-docker.pkg.dev/my-project/myapp-repo/myapp:2.3.0

As long as the GKE node's service account has appropriate Artifact Registry read permissions, this image is pulled without any additional, Kubernetes-specific image pull secret configuration.

Why This Avoids a Common Kubernetes Pain Point

Outside of this kind of native cloud integration, pulling from a private registry within Kubernetes typically requires creating and referencing a Kubernetes secret containing registry credentials — this integration removes that requirement entirely for GKE workloads pulling from Artifact Registry within the same Google Cloud project.

kubectl create secret docker-registry regcred --docker-server=... --docker-username=... --docker-password=...

This kind of manually managed secret becomes unnecessary when relying on this native integration instead.

Granting the Underlying Service Account Appropriate Permissions

The GKE node's (or a more granularly scoped Workload Identity-bound) service account still needs explicit Artifact Registry read permissions for this integration to actually function.

gcloud artifacts repositories add-iam-policy-binding myapp-repo \
  --location=us-central1 \
  --member=serviceAccount:gke-node@my-project.iam.gserviceaccount.com \
  --role=roles/artifactregistry.reader
Using Workload Identity for More Granular Permission Scoping

Rather than relying on broad node-level permissions, Workload Identity allows individual Kubernetes service accounts to be bound to specific Google Cloud service accounts, enabling more precisely scoped Artifact Registry access per workload.

gcloud iam service-accounts add-iam-policy-binding ...
Why GAR Kubernetes Integration Matters

This native integration significantly simplifies running container workloads on GKE that pull from Artifact Registry, removing the otherwise common need to separately manage Kubernetes image pull secrets for registry authentication.

Related content