Berechtigungen und Zugriffsmodell

Referenz zu Craftifact-Rollen, Repository-Berechtigungen, Gruppen, Robot-Accounts und Token-Scopes.

Wie Zugriff entsteht

Craftifact-Zugriff beginnt in der Instanz-Konfiguration. Rollen enthalten Repository-Berechtigungen, und role_assignments binden diese Rollen an Nutzer oder Gruppen. Gruppen können auf expliziten Mitgliedern, Mail-Domains oder Identity-Provider-Gruppen basieren.

Robot-Accounts nutzen dasselbe Rollenmodell wie menschliche Nutzer. Ihre owners legen fest, wer den Robot-Token erzeugen oder rotieren darf; die roles des Robot-Accounts legen fest, was der Token nach der Authentifizierung tun darf.

API-Tokens und Robot-Tokens tragen zusätzlich Paketfamilien-Scopes. Diese Scopes sind eine zusätzliche Schranke für Paketrouten wie Maven, Python, npm, OCI und Go; sie ersetzen keine Repository-Berechtigungen. Ein Token braucht sowohl den passenden Paketfamilien-Scope als auch die erforderliche Repository-Berechtigung.

Permission-Syntax

Repository-Berechtigungen verwenden diese Form:

<repository>:<domain>:<action>

Beispiele:

libs-release:artifact:read
containers:findings:suppress
oci:pull_gate:override

Wildcards werden unterstützt:

<repository>:*:* gewährt jede Domain und Action in einem Repository.
<repository>:artifact:* gewährt alle Artifact-Actions in einem Repository, aber keine Findings-, Composition-, License-Policy- oder Pull-Gate-Actions.
"*:*:*" gewährt alle Repository-bezogenen Berechtigungen und muss in YAML in Anführungszeichen stehen.

Legacy-Permissions wie artifact:add, artifact:exec_elevated, artifact:manage_findings, artifact:manage_licenses, artifact:manage_policies und sbom:* werden nicht mehr akzeptiert.

Verfügbare Berechtigungen

Berechtigung	Bedeutung
`artifact:read`	Paketartefakte, Paketmetadaten, Repository-Browse-Daten und Artefaktdetails für das ausgewählte Repository lesen.
`artifact:publish`	Neue Paketartefakte in ein schreibbares Hosted-Repository hochladen oder veröffentlichen.
`artifact:redeploy`	Erneut unter einer vorhandenen Paketkoordinate hochladen, wenn das Repository Redeploy erlaubt.
`artifact:delete`	Artefakte oder Paketinhalt löschen, soweit der Repository-Typ Löschung unterstützt.
`composition:read`	SBOM-basierte Composition-Daten, Dependency-Ansichten, Lizenz-Komponentenansichten und composition-basierte Evidence-Summaries lesen.
`composition:override_limits`	Dauerhafte Overrides für SBOM-Generierungslimits anlegen, wenn ein Subject unbegrenzte Analyse braucht.
`findings:read`	Vulnerability-, Secret- und Suppression-Oberflächen für Findings im ausgewählten Repository lesen.
`findings:suppress`	Vulnerability-Suppressions erstellen, erneuern, widerrufen und verwalten, einschließlich detaillierter Suppression-Verwaltungsfelder.
`license_policy:read`	License-Policy-Status, Komponenten-Lizenzergebnisse und License-Policy-Entscheidungen für das ausgewählte Repository lesen.
`license_policy:configure`	Repository-Lizenz-Policys konfigurieren, wenn nutzerverwaltete Policy-Konfiguration aktiviert ist.
`pull_gate:read`	Pull-Gate-Status lesen, der Paket-Discovery und Abruf beeinflusst.
`pull_gate:inspect`	Pull-Gate-Entscheidungen, gehaltene Artefakte, Decision Logs und evidence-relevanten Policy-Status prüfen.
`pull_gate:override`	Pull-Gate-Holds per Fast-track oder Override freigeben, soweit die Policy Nutzeraktionen erlaubt.

Einige Lese-Flows kombinieren mehrere Domains. Least-Privilege-Evidence-Sammlung braucht zum Beispiel Artifact-Lesezugriff, Composition-Lesezugriff, Findings-Lesezugriff, License-Policy-Lesezugriff, Pull-Gate-Inspect-Zugriff und einen passenden Token-Scope für jede ausgewählte Repository-Familie.

Typische Rollenformen

Nutze die kleinste Rollenform, die zum Workflow passt. Diese Beispiele zeigen die Absicht; passe Repository-Namen an deine Instanz an.

roles:
  - name: release-reviewer
    permissions:
      - "libs-release:artifact:read"
      - "libs-release:composition:read"
      - "libs-release:findings:read"
      - "libs-release:license_policy:read"
      - "libs-release:pull_gate:inspect"

  - name: package-publisher
    permissions:
      - "libs-release:artifact:read"
      - "libs-release:artifact:publish"
      - "libs-release:artifact:redeploy"

  - name: vulnerability-triage
    permissions:
      - "libs-release:artifact:read"
      - "libs-release:composition:read"
      - "libs-release:findings:read"
      - "libs-release:findings:suppress"

  - name: policy-manager
    permissions:
      - "libs-release:license_policy:read"
      - "libs-release:license_policy:configure"
      - "libs-release:pull_gate:read"
      - "libs-release:pull_gate:inspect"
      - "libs-release:pull_gate:override"

Für Automation weist du Rollen einem Robot-Account zu und erzeugst danach einen Token mit nur den Paketfamilien-Scopes, die die Integration braucht. Ein CI-Job, der npm-Pakete veröffentlicht, sollte zum Beispiel keinen OCI-Scope erhalten, wenn er keine OCI-Routen nutzt.

Praktische Grenzen

Repository-Berechtigungen beziehen sich auf Repository-Namen. Wenn eine Rolle nur libs-release:artifact:read gewährt, gewährt sie keinen Zugriff auf ein Repository namens containers.

Leseberechtigungen sind domain-spezifisch. artifact:read impliziert keine Findings-, Composition-, License-Policy- oder Pull-Gate-Sichtbarkeit.

Schreibende Berechtigungen sind ebenfalls domain-spezifisch. findings:suppress gewährt keine Artifact-Publish-Rechte, und license_policy:configure gewährt keine Pull-Gate-Override-Rechte.

Die Repository-Einstellung read_only und repository-spezifische Policy-Einstellungen können Verhalten weiterhin einschränken. Ein Nutzer kann artifact:publish haben, aber ein schreibgeschütztes Repository blockiert trotzdem Schreibzugriffe.