Robot-Account anlegen und Token nutzen

Wie du einen Robot-Account per Control Plane deklarierst, ihn in Craftifact als Owner nutzt und den Token korrekt einsetzt.

Kurzpfad

Öffne die Control Plane und gehe zur gewünschten Instanz.
Ergänze in Effektive Konfiguration unter robot_accounts einen neuen Eintrag mit id, owners, roles und optionaler token_policy.
Speichere die Änderung und nutze Config deployen, damit der Robot-Account in der aktiven Instanz-Konfiguration landet.
Melde dich anschließend in Craftifact mit einem Nutzer an, der in owners für diesen Robot-Account eingetragen ist.
Öffne in Craftifact den Tab Robot accounts in der Hauptnavigation des Explorers zwischen Browse und Dependencies.
Wähle den Robot-Account aus, setze die gewünschte Laufzeit und die benötigten Paket-Scopes, dann generiere den Token.
Hinterlege den Token im aufrufenden Tool und nutze ihn per Bearer-Token oder per Basic Auth.

Beispiel in der Instanz-Konfiguration

robot_accounts:
  - id: acceptance-test
    description: A robot for executing the acceptance test.
    owners:
      - some.developer@example.com
    roles:
      - a-defined-role-with-necessary-privileges
    token_policy:
      default_ttl_days: 30
      allow_infinite_ttl: false
    enabled: true

Wichtig dabei ist:

owners legt fest, welche Nutzer Tokens für diesen Robot-Account erzeugen dürfen.
roles definiert, mit welchen Rechten der Robot später in Craftifact arbeitet.
token_policy steuert Default- und Maximal-Laufzeiten für Tokens dieses Robot-Accounts.

Wenn du owners per E-Mail-Adresse angibst, muss dieser Nutzer später auch wirklich in der Instanz vorhanden sein.

Was in Craftifact passiert

Nach dem Deploy erscheint der Robot-Account für seine Owner im Tab Robot accounts in Craftifact. Nutzer ohne Berechtigung zur Robot-Account-Verwaltung sehen diesen Tab gar nicht.

Der Tab ist zweigeteilt aufgebaut:

Links siehst du die Liste der Robot-Accounts, die du besitzt.
Rechts siehst du den aktuell ausgewählten Robot-Account mit Eigentümern, vergebenen Rollen, Token-Status, TTL-Steuerung, Scope-Auswahl und Token-Aktionen.

Die Liste lässt sich nach Robot-ID und Beschreibung filtern. Gefiltert wird vor dem Paging, und das Paging zeigt fest 8 sichtbare Zeilen.

Dort kann der Owner:

den Token mit passender Laufzeit erzeugen,
die Paket-Scopes auswählen, inklusive Schnellaktionen für alle Scopes oder keine Scopes,
einen vorhandenen Token widerrufen und neu erzeugen.

Der erzeugte Token wird nur einmal angezeigt und automatisch in die Zwischenablage kopiert. Wenn du einen neuen Token generierst, wird der bisherige widerrufen. Eine unendliche TTL bleibt nur dann auswählbar, wenn die Richtlinie des Robot-Accounts das erlaubt.

Hintergrund: warum der Token erst in Craftifact erzeugt wird

In der Control Plane setzt die Administration die Leitplanken: welchen Robot-Account es gibt, wer ihn als Owner nutzen darf, welche Rollen er hat und welche Token-Laufzeiten erlaubt sind. Die eigentliche Nutzung wird dann an diese Owner delegiert, in der Praxis oft an Entwickler. Du kannst den Token in Craftifact innerhalb dieser Vorgaben selbst passend konfigurieren, holen und bei Bedarf erneuern, ohne dafür jedes Mal wieder die Administration in der Control Plane zu brauchen.

Robot-Account-Details lesen

Der Detailbereich soll drei Fragen ohne weiteren Konfigurationsabgleich beantworten:

Welche Owner diesen Robot-Account nutzen dürfen
Welche Rollen und effektiven Rechte er hat
Welche Token-Grenzen aktuell gelten

Auf breiten Screens stehen Token-Einstellungen, Token-Aktionen und Account-Details nebeneinander. Rollen werden zu lesbaren Berechtigungs-Zusammenfassungen gruppiert, damit du die effektive Rechteform vor dem Token-Minting direkt prüfen kannst.

Token verwenden

Für Requests gegen Craftifact kannst du den Token auf zwei Arten mitsenden:

Als Bearer-Token im Header Authorization: Bearer <token>.
Per Basic Auth mit dem Token als Passwort.

Bei Basic Auth kannst du als Benutzername entweder die Robot-ID oder den Platzhalter __token__ verwenden. Empfehlenswert ist die Robot-ID, zum Beispiel acceptance-test, weil du an der nutzenden Stelle später direkt erkennst, welchem Robot-Account der Token zugeordnet ist. Mit __token__ funktioniert es ebenfalls, ist aber weniger gut lesbar.

Beispiel mit Basic Auth:

Benutzername: acceptance-test
Passwort: <token>

Typische Fehlerquellen

Der Robot-Account ist zwar gespeichert, aber die aktuelle Konfiguration wurde noch nicht mit Config deployen ausgerollt.
Der Nutzer ist nicht als Owner eingetragen oder noch nicht in der Instanz vorhanden.
Die Rollen des Robot-Accounts enthalten nicht die Berechtigungen, die der spätere Zugriff braucht.
Ein neuer Token wurde generiert, aber die aufrufende Integration verwendet noch den widerrufenen alten Token.
Der Tab Robot accounts fehlt, weil der angemeldete Nutzer auf dieser Instanz keine Berechtigung zur Robot-Account-Verwaltung hat.