Neon Law | A private image registry

A private image registry

With storage in place, the provisioner creates the one private Artifact Registry repository that every navigator container image lives in, and the identities that push to and pull from it:

A Docker-format repository (default navigator) at your-region-docker.pkg.dev/your-project-id/navigator.
A keep-the-last-10-versions cleanup policy — a KEEP rule retaining the last 10 versions of each image plus a DELETE rule for everything else. Retention is a count rather than an age on purpose: an age-based rule is only safe while releases outrun it, and releases are tag-driven, so a quiet fortnight under the old 7-day rule would have let the registry delete the versions production was running. A count cannot expire. Keep policies take precedence over delete policies, which is what makes the pair mean "keep ten, delete the rest" — the delete half matches every version, so it is never applied alone.
A CI push identity (navigator-ci-pusher service account) with a repo-scoped roles/artifactregistry.writer binding, plus a GitHub Workload Identity federation pool and provider so CI authenticates keyless — no downloaded service-account key — pinned to this one repository and to the refs allowed to publish.
A repo-scoped roles/artifactregistry.reader binding for the GKE Autopilot node identity, so the cluster can pull.

Two values decide whether that federation works at all, and both are easy to get wrong in a way nothing reports:


issuerUri           https://token.actions.<your-tenant>.ghe.com   # NOT token.actions.githubusercontent.com
attributeCondition  assertion.repository == '<owner>/<repo>'
                        && (assertion.ref == 'refs/heads/main' || assertion.ref.startsWith('refs/tags/'))

Presenter notes

The registry is private: only principals inside this project may pull, which is why the cluster's node service account gets an explicit reader binding rather than relying on a public image. The repository create is a long-running operation that treats a 409 Conflict as already-exists, and the cleanup policy is a PATCH; both are safe to re-apply, keeping this step as idempotent as the rest.

Push access is keyless, and the two values above are where a day disappears. A GitHub Enterprise data-residency tenant issues its own OIDC tokens. If your repository lives on <tenant>.ghe.com, the pool must trust that tenant's issuer; every public federation tutorial assumes github.com, and a pool pinned to token.actions.githubusercontent.com is accepted at create time, reports ACTIVE, and then fails every single token exchange. Nothing warns you, because nothing is wrong until a workflow asks for a token. Read the issuer off the tenant instead of copying one:


curl https://token.actions.<your-tenant>.ghe.com/.well-known/openid-configuration

The condition pins the full owner/repo, not the owner alone. Owner-scoping sounds equivalent and is not: it admits every repository in the org, so any one of them can mint a token that pushes your production images. Pinning the whole slug also refuses a fork for free, because a fork carries its own repository claim. The ref clause is the second half — only main and release tags may publish, so an arbitrary branch is refused too.

Both refusals happen at the token exchange, which is the property worth internalising: a run that should not publish fails at the authenticate step and never reaches the push. When you verify this, check which step failed. A run that fails at docker push instead means the condition let the token through and the IAM binding caught it — the right outcome by luck rather than by design, and a condition still to fix.

One last trap, and the reason the provisioner is worth re-running rather than hand-fixing: an ensure that only ever creates cannot repair any of this. A provider built against the wrong issuer answers the create with 409, so a create-only provisioner reports "already exists" over a resource that can never authenticate. ops gcp hub setup converges instead — it PATCHes the existing provider onto the current issuer and condition, and it replaces the impersonation binding rather than appending to it, so a principal left behind by an org rename actually loses access. An additive binding can never revoke, and a rename is exactly when you need it to.

View all slides Open display