ankra registry
Manage the organisation’s Ankra registry. Every organisation publishes to a private project on the Ankra registry. Ankra mints the logins its own lanes use - the organisation’s ci and pull robots, and one push robot per application - and these commands cover the robot accounts you need on top of that: a login for CI you run outside Ankra, a laptop pushing an image by hand, or a cluster Ankra does not manage pulling from the project. ‘ankra registry robots list’ shows both: yours, and the ones Ankra manages. A robot account is bound to one registry project. ‘ankra registry projects’ creates extra projects beside the organisation’s own, so a robot can be given access to only what is kept in one of them. Every project has a storage limit; a full one refuses every push. ‘ankra registry storage’ shows how full it is, what fills it, the image retention policy that frees it, and asks Ankra for more.ankra registry projects
Create, list and delete the organisation’s registry projects. Every organisation has one project on the Ankra registry, named default here, and everything it publishes lands there. A robot account is bound to one project, so a robot on the default project reaches all of it. An extra project is how you give a login less: push what should be kept apart into the extra project and bind a robot to it with ‘ankra registry robots create <name>--project <project>’.
An extra project is private and has the same scan policy, retention policy and
storage quota as the default one. Deleting one never deletes anything else on
the way: a project that still holds repositories, or that robot accounts are
still bound to, is refused.
ankra registry projects create
Create an extra registry project for the organisation. The name is 2 to 30 lower-case letters, digits and single hyphens; ‘default’ is the organisation’s own project and is reserved. The project is private and has the same scan policy, retention policy and storage quota as the default one. Bind a robot account to it with ‘ankra registry robots create <name>--project
<project>’.
ankra registry projects delete
Delete an extra registry project. Nothing else is deleted on the way. A project that still holds repositories is refused until they are deleted from the registry, and one that robot accounts are still bound to is refused until they are revoked. The organisation’s own project (default) cannot be deleted.ankra registry projects list
List the organisation’s registry projects: its own (default) first, then the extra ones, each with the path images are pushed under, how many repositories it holds and how many of your robot accounts are bound to it. With--registry and --admin-credential it lists the projects of a Harbor your
organisation runs itself instead, as that credential sees them - the names to
bind a robot to with ‘ankra registry robots create <name> --registry …
--project <project>’. That listing acts as the admin credential, so it needs
credentials.reveal.
ankra registry robots
Create, list, rotate and revoke robot accounts on the organisation’s registry project. A robot is a named login bound to one registry project: it reaches the organisation’s project and nothing else on the registry. It holds a preset - push (push and pull) or pull - or its own list of permissions, and can be set to expire. Its secret is shown once, when it is created or rotated; the login is also stored as the managed registry credential ankra-harbor-robot-<name>, so it can be referenced from clusters and applications like any other registry credential. Revoking a robot deletes it from the registry and drops that credential in one step. The robots Ankra mints for its own lanes (ci, pull, one per application) are listed too. They are managed: Ankra rotates them and hands the new secret to the builds and clusters that use it, so ‘rotate’ and ‘delete’ refuse them.ankra registry robots create
Create a robot account on the organisation’s registry project and show its secret once. The name is 2 to 32 lower-case letters, digits and hyphens. The registry login becomes robot$<project>+user-<name>.--scope push (the default) grants push and
pull; --scope pull grants pull only. For anything else - a cleanup job that
deletes artifacts, a release job that moves tags, a scanner - grant exactly
what it needs with --permission, repeated or comma-separated, instead of a
scope; ‘ankra registry robots permissions’ lists what can be granted. Whatever
it holds, the robot reaches the organisation’s project and no other.
--expires-in-days makes the registry stop honouring the robot after that many
days; without it the robot never expires. --project binds the robot to one of
the organisation’s extra registry projects instead of its own (‘ankra registry
projects list’ shows them); it then reaches that project and nothing else.
--registry creates the robot on a Harbor your organisation runs itself instead:
name the OCI registry entry it is integrated as (‘ankra helm registries list’
shows them) and, with --admin-credential, a registry credential of the organisation
that may manage robot accounts there (project administrator on the project).
Ankra acts on that registry only with that credential, never its own; a robot
login Ankra manages cannot be used. --project is required there: the one
project of that registry the robot is bound to, such as collectorcharts, and
the only one it reaches (‘ankra registry projects list --registry …
--admin-credential …’ shows them). Rotate, delete, get and list work the
same afterwards.
The secret is printed exactly once, with
a docker login command that reads it from stdin - copy it now, it is not stored
anywhere you can read it back from. The secret is never put on a command line,
where the shell history and ‘ps’ would keep it. Rotate it with ‘ankra registry robots rotate’ if it
is lost or leaked.
Creating a robot needs the credentials.write permission. A --permission list
that reaches past repository:pull and repository:push (deleting artifacts,
moving tags, and the like) also needs credentials.reveal, and so does a robot on
an integrated registry (--registry), which is minted by acting as the admin
credential. With --permission or
--expires-in-days the CLI first checks that the platform offers them by
reading the robot listing, and with --project that the organisation has the
project; a token without credentials.read skips those checks, and if the
robot then comes back broader, longer-lived or on another project than asked
it is deleted again before its secret is shown.
ankra registry robots delete
Revoke a robot account: delete it from the registry and drop the managed credential holding its login. Everything still logging in with the robot stops working, which is the point of a revoke. Prefer ‘rotate’ when the robot should keep working under a new secret. A robot Ankra manages is refused: it is not yours to revoke.ankra registry robots get
Show one robot account: its registry login, what it may do, the project it is bound to, the managed credential holding its login, and when it was created, last rotated and expires. One of your own robots is read by its name; one Ankra manages by the name the listing gives it (ci, pull, app-<application id>). The secret is never shown here; rotate the robot to get a new one.ankra registry robots list
List every robot account the organisation holds on its registry project. Your own robots come first, then the ones Ankra manages: the organisation’s ci and pull robots and one push robot per application. Each row shows the robot’s kind, registry login, what it may do, the project it is bound to, when it expires, and when it was created and last rotated. Secrets are never listed.--kind narrows the listing: user (the ones you created), managed (everything
Ankra minted), organisation (ci and pull) or application. Managed robots are
shown so you can see every login that reaches the organisation’s images; they
are rotated by the lane that owns them, not from here.
ankra registry robots permissions
List the permissions a robot account can be created with. Each one is a value for ‘ankra registry robots create--permission’. They are
all rights on the content of the organisation’s own registry project - pulling,
pushing, listing and deleting repositories and artifacts, managing tags,
scanning - never on the project’s settings or on any other project.
ankra registry robots rotate
Mint a new secret for a robot account and show it once. The previous secret stops working the moment the registry answers, which makes this the response to a leaked or lost secret. Update every place that logs in with the robot afterwards. A robot the registry no longer has is minted again under the same name, with the same permissions and the rest of its lifetime. A rotation never extends a robot: one that has expired is refused, and so is a robot Ankra manages. Asks first, because a mistyped name would take another robot’s consumers down;--yes skips the prompt for scripts.
ankra registry storage
See how full the organisation’s registry is, free space, or ask for more. Every registry project has a storage limit (50 GiB by default). Once a project is full the registry refuses every image push to it, so builds stop publishing. Run on its own, this shows the usage against the limit for each project.ankra registry storage buy
Set how many paid storage blocks the organisation holds on top of its included registry storage. Each block adds its size to the limit of every registry project and is billed monthly for the days it is held.--blocks is the number
to hold, not the number to add; 0 stops paying for extra storage.
It shows the limit and the monthly price before and after, and asks first;
--yes skips the prompt. Lowering it below what the registry already holds is
refused: free space first. For more than the self-serve maximum, ask Ankra
with ‘ankra registry storage request’.
ankra registry storage repositories
Show which repositories take the registry space, largest first. Repositories under ankra-ci/ hold the images Ankra builds and scans in CI, one per pipeline run and pull request; they are usually what fills the registry. The others hold the images your applications publish. The Retention column names the rule that governs each repository, or the organisation policy. Sizes are approximate: a layer shared by several images is counted for each of them, so use the sizes to rank repositories, not to add up to the usage. This reads every image in the registry and can take a while.ankra registry storage request
Ask Ankra for a bigger registry storage limit.--size is the limit you need
for each registry project, in GiB (more than today’s, at most 10240); --reason
says why. The Ankra team reviews the request and you are notified when it is
decided; once approved the registry applies the new limit within about 5
minutes. ‘ankra org limits list’ shows the request’s state.
ankra registry storage retention
Show or change the image retention policy: which images the registry keeps. An image is kept when it was pushed within the policy’s days, or is among the newest images of its repository; everything else is deleted when retention runs (daily). The newest image of every repository is never deleted. Deleted images free their space at the registry’s next garbage collection (weekly). The organisation policy governs every repository. A rule replaces it for the repositories its pattern matches - for example a shorter one for CI images:ankra registry storage retention rule
Add, remove and list retention rules. A rule replaces the organisation policy for the repositories its pattern matches. Patterns are lower-case letters, digits and . _ / - with * matching within one path segment and ** across segments; braces and commas are not accepted, so write one rule per pattern. ’**’ alone is the organisation policy itself (‘retention set’). A rule needs an organisation policy that keeps something: when the policy in force keeps nothing, the platform refuses rules until one is set with ‘ankra registry storage retention set’.ankra registry storage retention rule add
Add a retention rule for the repositories a pattern matches, or change the rule already stored for that pattern.--keep-days and --keep-latest work as in ‘retention set’; a flag not passed
takes the existing rule’s value, or the organisation policy’s for a new rule.
--application ties the rule to an application, so it shows with it.
A rule that keeps fewer images than what governs those repositories now asks
first; --yes skips the prompt. Quote the pattern so the shell does not expand
it.
ankra registry storage retention rule list
List the retention rulesankra registry storage retention rule remove
Remove the retention rule for a pattern; the repositories it matched follow the organisation policy again. When that policy keeps fewer images than the rule did, it asks first;--yes skips the prompt.
ankra registry storage retention run
Start the retention cleanup now instead of at its daily time: images the policy does not keep are deleted. The space they held is freed at the registry’s next garbage collection (weekly), not at once.ankra registry storage retention set
Change the organisation retention policy: the one every repository without a rule follows.--keep-days keeps every image pushed in that many days (0 turns it off, so
only the newest are kept); --keep-latest always keeps that many newest images
of each repository (at least 1). A flag not passed keeps its current value.
--reset goes back to the platform default. Rules are not touched.
A change that keeps fewer images asks first, because what it no longer keeps
is deleted at the next retention run; --yes skips the prompt.
The change is made to the retention as it is stored when it is written: if
someone else changes it between the read and the write, the platform refuses
the write and the change is applied again to the new retention, once.