Zugriffs-Token

Ein Registry-Token ist die Passwort-Hälfte einer Registry-Anmeldung. Der Benutzername ist immer dein Registry-Namespace, nie deine E-Mail-Adresse.

Token legst du im Portal unter Container Registry → Zugriffs-Token an.

Der Token wird einmal angezeigt

Beim Anlegen zeigt ihn das Portal mit Speichere diesen Token jetzt. Er wird nicht erneut angezeigt. zusammen mit fertigen Snippets für Docker, Podman und CI. Später ist der Wert nicht mehr auslesbar. Verlierst du ihn, lösch den Token und leg einen neuen an.

Was ein Token erreicht

Ein Token erreicht immer nur Repositories unter deinem eigenen Registry-Namespace. Das Feld Repository-Bereich im Anlegen-Dialog schränkt das weiter ein:

• Leer gelassen erreicht der Token jedes Repository unter deinem Registry-Namespace, auch später angelegte. Die Spalte Berechtigungen zeigt Alle Repositories.
• Mit Namen, durch Komma getrennt, erreicht der Token diese Repositories und die darunter verschachtelten, sonst nichts. my-app deckt registry.itsh.dev/<dein-slug>/my-app und registry.itsh.dev/<dein-slug>/my-app/worker ab.

Ein Bereich passt nur auf ganze Pfadsegmente

my-app deckt my-app-v2 nicht ab. Eine Pipeline, die mehrere Images pusht, braucht jedes davon in der Liste, oder einen gemeinsamen Elternpfad wie my-app mit den Images darunter als my-app/api und my-app/web.

Trag die Namen ohne das Präfix <dein-slug>/ ein, so wie das Portal sie unter Repositories auflistet. Ein mitkopiertes Präfix wird entfernt. Die Namen folgen den Regeln der Registry: Kleinbuchstaben und Ziffern, getrennt durch ., _ oder -, mit / zwischen Pfadsegmenten. Alles andere wird abgelehnt, und es wird kein Token angelegt.

Ein Push oder Pull außerhalb des Bereichs wird als unauthorized abgewiesen, genau wie ein Pfad unter dem Registry-Namespace von jemand anderem. Den Bereich kannst du danach nicht mehr ändern: leg einen neuen Token an und lösch den alten.

Gib CI-Pipelines, Dienstleistern und anderen Dritten einen Token mit dem Bereich der Repositories, die sie wirklich bauen oder ausrollen. Ein abgeflossener Token legt dann nur diese offen und sonst nichts.

Ein Datum im Feld Ablauf lässt den Token am Ende dieses Tages aufhören zu funktionieren, in der Zeitzone deines Browsers. Anmeldungen damit werden dann abgewiesen wie mit einem gelöschten Token. Der Token bleibt in der Liste und zählt zum Limit, bis du ihn löschst. Leer gelassen läuft der Token nicht ab.

Pull-only-Token

Setzt du im Anlegen-Dialog Nur Pull, entsteht ein Token, der nur pullen kann. Push und Löschen werden abgewiesen, in jedem Repository, das sein Bereich abdeckt. Die Spalte Berechtigungen kennzeichnet ihn mit Nur Pull.

Nimm so einen überall, wo Images ausgerollt, aber nie gebaut werden:

• Kubernetes-Cluster und andere Deploy-Ziele, die deine Images pullen
• Dritte, die deine Images ausrollen, ohne sie zu bauen

Die Einstellung lässt sich nach dem Anlegen nicht ändern. Um einen Token auf Nur Pull umzustellen oder zurück, leg einen neuen an und lösch den alten.

Anmelden

echo '<token>' | docker login registry.itsh.dev -u <dein-slug> --password-stdin

Podman nimmt dieselben Argumente:

echo '<token>' | podman login registry.itsh.dev -u <dein-slug> --password-stdin

Gib den Token über stdin weiter, nicht mit -p. Ein Token auf der Kommandozeile landet in deiner Shell-History und in der Prozessliste der Maschine, die den Befehl ausgeführt hat, und lässt sich nachträglich nicht einschränken.

In CI gehört der Token in den Secret-Store der Plattform und wird von dort referenziert. Der Tab CI/CD im Token-Dialog zeigt die Variablennamen für die gängigen Systeme.

Der Token hinter deinen Pull-Secrets

Beim Bereitstellen eines Kubernetes-Namespace entsteht ein Registry-Token namens k8s-pull-secret, der das Pull-Secret itsh-registry in diesem Namespace speist. Er steht wie jeder andere Token in der Liste, und wenn du ihn löschst, können die Pods in diesem Namespace nicht mehr pullen. Siehe Images und Pull-Secrets dazu, wie dieses Secret genutzt wird und was zu tun ist, wenn ein Namespace keins hat.

Wie viele, und widerrufen

Ein Konto hält 10 Token gleichzeitig, die für deine Namespaces angelegten k8s-pull-secret-Token eingerechnet. Ein weiterer lässt sich erst anlegen, wenn du welche löschst.

Das Löschen eines Tokens wirkt bei der nächsten Anmeldung. Bereits ausgegebene Zugangsdaten bleiben in einem laufenden Client bis zu 5 Minuten nutzbar, so lange gelten die kurzlebigen Sitzungstoken der Registry. Um einen abgeflossenen Token vollständig abzuschneiden, lösch ihn und pull oder starte danach alles neu, was ihn benutzt hat.

Wenn die Anmeldung scheitert

Ein falscher Benutzername oder ein Token, den es nicht mehr gibt, ergibt dies, mit leerer Begründung hinter dem Doppelpunkt:

Error response from daemon: Get "https://registry.itsh.dev/v2/": unauthorized:

Nach Häufigkeit: der Benutzername ist nicht der Registry-Namespace, der Token wurde gelöscht, vertippt oder ist abgelaufen, oder die Registry ist auf dem Konto nicht aktiviert. Dieselbe Meldung kommt, wenn die Registry gesperrt wurde.

Eine Anmeldung, die klappt, während der Push abgewiesen wird, ist etwas anderes. Entweder ist der Token pull-only, oder die Registry ist über ihrem Speicherlimit, das blockiert Schreibzugriffe und lässt Lesezugriffe in Ruhe (siehe Speicher und Bereinigung).

Wie es weitergeht

• Speicher und Bereinigung dazu, was beim Erreichen des Limits passiert
• Container-Registry für den Registry-Namespace und den ersten Push