Paketzugriff

Standardmäßig erreicht jeder mit Paketzugriff in deiner Organisation jedes Paket darin: Ein Mitglied eines Teams mit Schreibrecht für Pakete kann jedes Paket der Organisation veröffentlichen und löschen, egal zu welchem Repository es gehört. Zugriff pro Paket schränkt das ein, so wie GitHub Packages und GitLab es tun.

Nichts ändert sich, bis ein Owner der Organisation ihn einschaltet, für ein Paket oder für die ganze Organisation.

Was der Zugriff pro Paket bewirkt

Für ein Paket mit Zugriff pro Paket:

• Lesen lädt das Paket herunter. Schreiben veröffentlicht, fügt eine Datei hinzu und verschiebt einen Tag. Admin löscht außerdem Versionen und verknüpft das Repository oder hebt die Verknüpfung auf. Ein Registry-Robot löscht nie, egal welche Freigaben er hat.
• Die Sichtbarkeit bleibt unverändert. In einer öffentlichen Organisation kann weiterhin jeder jedes Paket lesen, und in einer eingeschränkten jeder angemeldete Nutzer. Der Zugriff pro Paket begrenzt dann, wer veröffentlichen und löschen darf. In einer privaten Organisation begrenzt er auch das Lesen.
• Er kann nur einschränken. Der Zugriff pro Paket gibt nie jemandem mehr, als die eigenen Paketeinstellungen der Organisation geben. Damit ein Team ein Paket veröffentlichen kann, brauchen seine Mitglieder Schreibrecht für Pakete in der Organisation (das Team Members hat es), und der Zugriff pro Paket beschränkt sie dann auf dieses Paket. Die einzige Ausnahme ist die Actions-Freigabe mit Schreibrecht, mit der die Jobs eines anderen Repositorys ein anderswo verknüpftes Paket veröffentlichen können.
• Verknüpftes Repository. Ein Paket ist mit einem Repository verknüpft, wenn es von einem Actions-Job dieses Repositorys veröffentlicht wird, über seine Metadaten (npm repository, das Container-Label org.opencontainers.image.source) oder in den Einstellungen des Pakets. Schalte Vom verknüpften Repository erben aus, um dich allein auf Freigaben zu stützen.

Zugriff pro Paket ist für jeden Pakettyp verfügbar, den die Registry ausliefert: Alpine, ALT, Arch, Cargo, Chef, Composer, Conan, Conda, Container, CRAN, Debian, generisch, Go, Helm, Maven, npm, NuGet, Pub, PyPI, RPM, RubyGems, Swift und Vagrant.

Einschalten

In der Konsole: Sicherheit › Zugriff › Paketzugriff.

• Standard der Organisation: Organisationsweit (der Standard) oder Pro Paket, für jedes Paket eines unterstützten Typs, das keine eigene Einstellung hat.
• Ein Paket konfigurieren: pro Paket Pro Paket, Organisationsweit oder Wie die Organisation, und ob es von seinem verknüpften Repository erbt. Das Paket muss noch nicht existieren: Eine Einstellung, die vor der ersten Veröffentlichung gemacht wird, gilt dafür.
• Freigabe hinzufügen auf einem konfigurierten Paket: ein Team (Lesen, Schreiben oder Admin) oder die Actions-Jobs eines Repositorys (Lesen oder Schreiben).

Oder mit der API, mit einem API-Token mit dem Scope policy:write (policy:read zum Lesen). Ein / in einem Paketnamen wird als %2F gesendet:

API=https://frem.sh/_app/api/v1/orgs/acme
curl -X PUT -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"mode":"granular","inherit_repo":true}' "$API/packages/container/team%2Fapp/access"
curl -X PUT -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"permission":"write"}' "$API/packages/container/team%2Fapp/access/teams/release-managers"
curl -X PUT -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"permission":"write"}' "$API/packages/container/team%2Fapp/access/actions/release-pipeline"

Geschützte Namen

Eine Schutzregel benennt Pakete nach Typ (oder jedem unterstützten Typ) und einem Namensmuster und legt fest, wer in sie veröffentlichen und wer sie löschen darf: Owner der Organisation, Registry-Robots, Mitglieder benannter Teams und die Actions-Jobs benannter Repositorys. Alle anderen werden abgewiesen, egal wie der Zugriff auf das Paket eingestellt ist. Passen mehrere Regeln auf ein Paket, müssen alle es erlauben.

Im Muster passt * auf beliebige Zeichen, auch ein /, und ? auf ein Zeichen; Groß- und Kleinschreibung spielt keine Rolle. Zum Beispiel beschränkt release/* mit Darf veröffentlichen: Registry-Robots, Actions-Jobs von release-pipeline Release-Images auf CI.

curl -X POST -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"type":"container","name_pattern":"release/*","push":{"owners":false,"robots":true,"actions":["release-pipeline"]},"delete":{"owners":true}}' \
  "$API/packages/protection-rules"

Paketlisten und Indizes

In einer Organisation, die Zugriff pro Paket nutzt, lassen Listen und Indizes die Pakete weg, die der Aufrufer nicht lesen kann, mit Namen und allen Versionen:

• die Paketliste der API, /api/v1/packages/<org>;
• die npm-Suche, die Helm-index.yaml, die NuGet-Suche (query), Composer-search.json und list.json, die Cargo-Suche, Chef-search und -universe, Conda-repodata.json, RubyGems- versions, CRAN-PACKAGES, die Conan-Suche und die Swift-Abfrage identifiers.

Die Registry prüft die Liste auf dem Weg nach draußen, was diese Anfragen typischerweise um weniger als eine Zehntelsekunde verlängert. Kann sie eine Liste nicht prüfen, antwortet sie mit 503 und Retry-After, statt sie ungefiltert anzuzeigen. Organisationen, die keinen Zugriff pro Paket nutzen, bekommen die Listen der Registry unverändert.

Wie eine Ablehnung aussieht

Eine abgelehnte Anfrage antwortet mit 403 und dem Grund (DENIED im Fehlerformat der Container-Registry), bevor irgendetwas geschrieben wird. Jede Ablehnung steht im Audit-Log der Organisation als package_access.denied, und eine abgelehnte Veröffentlichung oder Löschung zusätzlich als package.upload.refused oder package.delete.refused mit dem Grund package_access:<reason>.

Als Code

Das Configuration-as-Code-Modul verwaltet alles davon:

module "org" {
  source = "./modules/fremforge-org"
  org    = "acme"

  package_access_default = "legacy"
  packages = {
    "container/team/app" = {
      mode    = "granular"
      teams   = { release-managers = "admin" }
      actions = { release-pipeline = "write" }
    }
  }
  package_protection_rules = {
    releases = { type = "container", name_pattern = "release/*", push = { owners = false, robots = true } }
  }
}

Grenzen

• Eine Änderung an einer Einstellung, einer Freigabe, einer Regel oder den Mitgliedern eines Teams wirkt innerhalb einer Minute: Die Registry speichert ihre Entscheidungen kurz zwischen.
• Diese Listen werden nicht gefiltert: die Paketliste in der Weboberfläche, signierte Repository-Indizes (die Debian-Dateien Release/Packages, RPM-repodata, Alpine-APKINDEX, die Arch-Datenbank und die ALT-Basis-Dateien, deren Signatur ein Umschreiben brechen würde), komprimierte Varianten (PACKAGES.gz, repodata.json.bz2, die RubyGems-Familie specs.4.8.gz), die NuGet-v2-XML-Feeds und die Tag-Liste der Container. Sie zeigen Paketnamen und Versionen jedem, der die Pakete der Organisation lesen kann, aber nicht den Inhalt der Pakete.
• Ein Upload, der sein Paket nur innerhalb der hochgeladenen Datei benennt, wird gegen diesen Namen geprüft. Wo die Registry den Namen nicht lesen kann (ein Conda-.tar.bz2, ein xz-komprimiertes Debian-Control-Archiv oder Arch-Paket), wird der Upload in einer Organisation abgelehnt, die für diesen Typ Zugriff pro Paket nutzt. Verwende .conda oder gzip- bzw. zstd-Kompression.
• Ein RubyGems-Yank muss das Gem im Query-String nennen, zum Beispiel curl -X DELETE ".../rubygems/api/v1/gems/yank?gem_name=mygem&version=1.0.0". Ein Yank, der es nur in einem Formular-Body nennt, wird in einer Organisation abgelehnt, die für RubyGems Zugriff pro Paket nutzt.