Status: Akzeptiert

Kontext

Automatisierung via CLI braucht API-Tokens. Gleichzeitig soll der Aufrufer keine Secrets besitzen, und Requests sollen auf erlaubte Atlassian-Endpunkte beschränkt sein.

Entscheidung

Wir trennen in:

  • atlassian (unprivilegierte CLI)
  • atlassian-http-client (läuft als Tool-Eigentümer via sudo -Hu)

Token und Config liegen ausschließlich beim Tool-Eigentümer ($HOME/.config/atlassian/http-client + Token-Datei).

Die CLI baut nur URL-Templates mit {CLOUD_ID}/{SITE_SUBDOMAIN}; der http-client löst sie aus der Tool-Eigentümer-Config auf. Der http-client setzt eine Allowlist durch.

Konsequenzen

  • Aufrufer benötigt keine Secrets; Sicherheitsmodell ist einfach prüfbar.
  • Transparenz erfolgt über --dry-run (Token maskiert).
  • Tool-Eigentümer muss Config pflegen; Setup ist einmalig.

Alternativen

  • Token als Env beim Aufrufer: abgelehnt (Secret-Leak-Risiko).
  • Generischer curl ohne Allowlist: abgelehnt (zu viel Zugriff).
  • Tooling: proj-doku-tools (lokales Repo)