Pakketilgang

Som standard når alle med pakketilgang i organisasjonen din alle pakkene i den: et medlem av et team med skrivetilgang til pakker kan publisere til, og slette, hvilken som helst pakke i organisasjonen, uansett hvilket repository den hører til. Tilgang per pakke snevrer dette inn, slik GitHub Packages og GitLab gjør det.

Ingenting endres før en eier av organisasjonen slår det på, for én pakke eller for hele organisasjonen.

Hva tilgang per pakke gjør

For en pakke med tilgang per pakke:

• Les laster ned pakken. Skriv publiserer, legger til en fil og flytter en tag. Admin sletter i tillegg versjoner og kobler repositoryet til eller fra. En registerrobot sletter aldri, uansett hvilke tildelinger den har.
• Synligheten er uendret. I en offentlig organisasjon kan alle fortsatt lese alle pakkene, og i en begrenset organisasjon kan alle innloggede brukere det. Tilgang per pakke begrenser da hvem som kan publisere og slette. I en privat organisasjon begrenser den også lesing.
• Den kan bare snevre inn. Tilgang per pakke gir aldri noen mer enn organisasjonens egne pakkeinnstillinger gjør. For å la et team publisere én pakke må medlemmene ha skrivetilgang til pakker i organisasjonen (teamet Members har det), og tilgang per pakke holder dem da til den pakken. Det eneste unntaket er Actions-tildelingen med write, som lar jobbene i et annet repository publisere en pakke som er koblet et annet sted.
• Koblet repository. En pakke kobles til et repository når den publiseres av en Actions-jobb i det repositoryet, ut fra metadataene (npm repository, container-etiketten org.opencontainers.image.source), eller i pakkens innstillinger. Slå av Inherit from the linked repository for å stole bare på tildelinger.

Tilgang per pakke er tilgjengelig for alle pakketyper registeret leverer: Alpine, ALT, Arch, Cargo, Chef, Composer, Conan, Conda, container, CRAN, Debian, generic, Go, Helm, Maven, npm, NuGet, Pub, PyPI, RPM, RubyGems, Swift og Vagrant.

Slå det på

I konsollen: Sikkerhet › Tilgang › Pakketilgang.

• Organisasjonens standard: Organisation-wide (standard) eller Per package, for alle pakker av en støttet type som ikke har en egen innstilling.
• Konfigurer en pakke: per pakke Per package, Organisation-wide eller Follow the organisation, og om den arver fra det koblede repositoryet. Pakken trenger ikke å finnes ennå: en innstilling som gjøres før første publisering, gjelder for den.
• Legg til en tildeling på en konfigurert pakke: et team (read, write eller admin) eller et repositorys Actions-jobber (read eller write).

Eller med API-et, med et API-token med scopet policy:write (policy:read for å lese). En / i et pakkenavn sendes som %2F:

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"

Beskyttede navn

En beskyttelsesregel angir pakker etter type (eller alle støttede typer) og et navnemønster, og lister hvem som kan publisere til dem og hvem som kan slette dem: eiere av organisasjonen, registerroboter, medlemmer av navngitte team og Actions-jobbene i navngitte repositoryer. Alle andre avvises, uansett pakkens tilgangsinnstilling. Når flere regler treffer en pakke, må alle tillate det.

I mønsteret treffer * hvilke som helst tegn, også /, og ? ett tegn; store og små bokstaver spiller ingen rolle. For eksempel holder release/* med May publish: registry robots, Actions jobs of release-pipeline utgivelsesimager forbeholdt 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"

Pakkelister og indekser

I en organisasjon som bruker tilgang per pakke, utelater lister og indekser pakkene den som spør, ikke kan lese, med navn og alle versjoner:

• pakkelisten i API-et, /api/v1/packages/<org>;
• npm-søk, Helm index.yaml, NuGet-søket (query), Composer search.json og list.json, Cargo-søk, Chef search og universe, Conda repodata.json, RubyGems versions, CRAN PACKAGES, Conan-søk og Swift-oppslaget identifiers.

Registeret kontrollerer listen på vei ut, noe som vanligvis legger til mindre enn et tiendels sekund på disse forespørslene. Hvis det ikke kan kontrollere en liste, svarer det 503 med Retry-After i stedet for å vise den ufiltrert. Organisasjoner som ikke bruker tilgang per pakke, får registerets lister uendret.

Slik ser en avvisning ut

En avvist forespørsel svarer 403 med årsaken (DENIED i feilformatet til containerregisteret), før noe skrives. Hver avvisning står i organisasjonens revisjonslogg som package_access.denied, og en avvist publisering eller sletting også som package.upload.refused eller package.delete.refused med årsaken package_access:<reason>.

Som kode

Modulen for konfigurasjon som kode administrerer alt dette:

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 } }
  }
}

Begrensninger

• En endring i en innstilling, en tildeling, en regel eller medlemmene i et team trer i kraft innen ett minutt: registeret bufrer avgjørelsene sine en kort stund.
• Disse listene filtreres ikke: pakkelisten i webgrensesnittet, signerte repository-indekser (Debian Release/Packages, RPM repodata, Alpine APKINDEX, Arch-databasen og ALT-grunnfilene, der en omskriving ville ødelagt signaturen), komprimerte varianter (PACKAGES.gz, repodata.json.bz2, RubyGems-familien specs.4.8.gz), NuGet v2-XML-feedene og listen over container-tagger. De viser pakkenavn og versjoner til alle som kan lese organisasjonens pakker, men ikke innholdet i pakkene.
• En opplasting som bare oppgir pakkenavnet inne i den opplastede filen, kontrolleres mot det navnet. Der registeret ikke kan lese navnet (en Conda .tar.bz2, et xz-komprimert Debian-kontrollarkiv eller en Arch-pakke), avvises opplastingen i en organisasjon som bruker tilgang per pakke for den typen. Bruk .conda, eller gzip- eller zstd-komprimering.
• En RubyGems-yank må oppgi gemen i spørrestrengen, for eksempel curl -X DELETE ".../rubygems/api/v1/gems/yank?gem_name=mygem&version=1.0.0". En yank som bare oppgir den i et skjemainnhold, avvises i en organisasjon som bruker tilgang per pakke for RubyGems.