Skip to main content
An application publishes to your organisation’s private Ankra registry unless you say otherwise. If you already run Harbor, declare it on the application and Ankra publishes there, reads the published tags back from there, and pulls from there - including minting the robot account the build logs in with, if you let it. This guide is the operator’s side of Using your own registry: what Harbor needs to look like before you point an application at it, what Ankra creates once you do, and how to check it from the Harbor end.

​
The two credentials

Ankra talks to your Harbor with registry credentials of your organisation. A declaration names up to two of them, and they do different jobs.
The read credential is what makes a declaration usable rather than merely descriptive. Without one, Ankra records where the images live but cannot read their tags or pull them - so publish readiness, the demo build check and the deploy gate all keep reporting the application as never built, while it publishes healthily to a registry Ankra simply cannot see. It is also what the cluster pull secret is built from: declare a registry with no read credential and no pull secret is created at all.
Ankra does not mint robots for a registry you operate unless you hand it the keys. With no admin_credential_name, setup names the two Actions secrets the workflow reads and leaves them to you; your robots stay yours and untouched.

​
What Harbor needs first

1

Create the project

Ankra publishes into a project you already have; it never creates one. Create the project that the declaration’s oci://<host>/<project> names, and decide whether it is public or private - Ankra works with either, and a private project is why the pull secret exists.
2

Give the project-administrator credential a Harbor user

Make the account behind admin_credential_name a Harbor user with the Project Admin role on the project, and store it as a registry credential in Ankra.
A project-scoped robot cannot administer robots. Harbor’s project-level robot permission set has no robot create/update/delete, so a declaration whose admin_credential_name points at an ordinary project robot fails to mint the application’s robot - with a permission error from Harbor, not from Ankra. Use a Harbor user with Project Admin, or a system-level robot granted the robot-account permissions.
3

Store a read credential

Create the pull account - a system robot with pull/list/read across the projects Ankra reads is the tidiest - and store it as a second registry credential. This is the one that ends up inside every cluster’s pull secret, so scope it to pull, not push.

​
Declaring it on an application

Declare the registry when you create the application where you can: the setup job generates the build workflow from the declaration the application is created with, so a registry added afterwards leaves a workflow that logs in to the wrong one until the application is reconciled and its setup pull request merged.
Where your Harbor’s repository layout is not Ankra’s <project>/<app>/<component> nesting, say so rather than reorganising Harbor: --flat-repositories addresses components as <project>/<component>, and --component-repository backend=commerce-backend names one outright. Both are used by publish readiness, the deploy gate and the generated workflow, so they describe what your pipeline already pushes.

​
The robot Ankra mints

With a project-administrator credential in the declaration, every application gets a push robot of its own. Nothing else shares that login, so a leaked repository secret is rotated or revoked for that one application, and a deleted application takes its robot with it.
The same lives under Settings → Image registry in the portal, and on the API at /api/v1/org/applications/{application_id}/registry-robot (GET, POST with {"rotate": true|false}, DELETE).

​
Checking it from the Harbor end

Project robots are not returned by Harbor’s system robot listing; query them with the project id.
A healthy application robot comes back enabled, with expires_at: -1 and exactly push repository plus pull repository on its own project.

​
Pull secrets in your clusters

The generated manifests reference the pull secret through imagePullSecrets, and Ankra keeps that Secret in place for you - per cluster and per namespace, without you registering anything.
  • On every deploy, the target namespace is added to that cluster’s registry pull-secret resource for the Secret the declaration names (harbor-registry above, ankra-registry-pull by default), and the resource is re-applied so the Secret exists in the new namespace.
  • A cluster carries one resource per Secret name, so an application pulling from your Harbor coexists with every other application pulling from Ankra’s own registry - registering a namespace on one never rewrites the other’s.
  • Rotation fans out: rotating the robot flips the deployed resources so the new login replaces the old one in each cluster.
  • Clusters imported before the registry existed get the resource created on the spot.
The Secret is built from the declaration’s read credential, at the declared host. A declaration with no read credential registers no namespace and creates no Secret, which surfaces in the cluster as ImagePullBackOff on a private project rather than as an error in Ankra.

​
Verifying the whole path

ankra application publish-readiness <application-id> answers the four questions that matter, and distinguishes “nothing published” from “cannot see”, so an unreadable registry never reads as an empty one.

​
Troubleshooting

Using your own registry

The declaration’s every field, and how components inherit it.

Robot accounts

The per-application robot on Ankra’s own registry.

Registry credentials

Storing the credentials this guide names.

CI/CD pipeline

The build workflow that logs in with the robot.