API-nøkkeltilganger

En API-nøkkel autentiserer et program — CI, et skript, Terraform — mot Frostmoln-API-et. Hver nøkkel bærer tilganger (scopes): listen over hva den har lov til å gjøre. Frostmolns nøkler følger minste privilegium, så en nøkkel gjør ingenting før du angir hva den får gjøre.

Listen serveres av plattformen

Det finnes ingen fast liste å kopiere fra denne siden. Katalogen ligger i plattformen, og samsvarer derfor alltid med hva som godtas når en nøkkel opprettes. Les den der du jobber:

Hvor	Hvordan
Portalen	Innstillinger → API-nøkler → Opprett API-nøkkel. Tilgangsvelgeren viser hver tilgang med en beskrivelse av hva den gir.
CLI	fm account api-key scopes (legg til -o json for skript).
Terraform	Datakilden frostmoln_api_key_scopes — kjør terraform console og deretter data.frostmoln_api_key_scopes.all.scopes.

Slik ser en tilgang ut

En tilgang skrives som <tjeneste>:<handling>:

compute:read     lese compute-ressurser
compute:write    opprette, endre og slette dem
storage:read     lese volumer og buckets
billing:read     lese fakturaer og forbruk

read og write er de to handlingene API-et håndhever i dag. write dekker enhver endring — opprette, oppdatere, slette, og handlinger som start/stopp/omstart. Det finnes ingen egen "opprette, men ikke slette"-tilgang: når du trenger det skillet, bruk en tilgangspolicy.

Gi read og write, ikke de finere formene

Katalogen viser også tredelte oppføringer som compute:instances:read, og nøkkelopprettelsen godtar dem. De håndheves ikke som nøkkeltilganger — de hører til tilgangspolicy-motoren. En nøkkel som bare har compute:instances:read opprettes uten feil og nektes deretter på hvert compute-kall, med en 403 som ikke forklarer hvorfor.

Det samme gjelder de øvrige verbene i katalogen (action, create, update, delete, list): de kan gis, men tjenestene sjekker :read og :write. Gi dem.

Jokertegn

Tilgang	API-nøkkel	Arbeidslastidentitet
* (alt)	Avvises — WILDCARD_SCOPE_NOT_ALLOWED	Avvises — WILDCARD_SCOPE_FORBIDDEN
compute:* (én tjeneste)	Tillates	Avvises — WILDCARD_SCOPE_FORBIDDEN
compute:read	Tillates	Tillates

En Workload Identity-binding er bevisst strengere enn en API-nøkkel: en føderert pod-legitimasjon må navngi nøyaktig hva den trenger.

Merk at compute:* virkelig gir alt den tjenesten tilbyr, nå og i fremtiden. To navngitte tilganger er nesten alltid et bedre valg.

Regler verdt å kjenne

• Minst én tilgang kreves. En tom liste avvises med SCOPES_REQUIRED, og en ukjent tilgang med INVALID_SCOPES (når en nøkkel opprettes; INVALID_SCOPE når en nøkkel eller en arbeidslastbinding oppdateres).
• En nøkkel kan aldri overgå deg — i det øyeblikket du oppretter den. Tilgangene begrenses av tilgangene til identiteten som oppretter nøkkelen; å be om mer feiler med SCOPE_EXCEEDS_PERMISSIONS. Dette sjekkes når nøkkelen opprettes eller tilgangene endres. Blir dine egne tilganger redusert senere, beholder allerede utstedte nøkler tilgangene sine — trekk dem tilbake og utsted dem på nytt.
• Organisasjonskontroll styres ikke av tilganger. Å slette en organisasjon, endre medlemmer og overføre eierskap autoriseres av organisasjonsrollen din, ikke av nøkkelens tilganger — en nøkkel opprettet av en eier kan gjøre det uansett hva den er begrenset til. Ikke regn en smal tilgangsliste som beskyttelse mot endringer på organisasjonsnivå: opprett automasjonsnøkler fra en konto som ikke er organisasjonseier.

Å velge tilganger

Ta utgangspunkt i oppgaven nøkkelen utfører, ikke i tjenesten den kaller.

Nøkkelen gjør dette	Gi
Overvåking / inventar	compute:read, storage:read, network:read — lesetilgangene for det den inspiserer
CI som setter ut instanser	compute:read, compute:write
Starte en tjeneste på nytt etter plan	compute:read, compute:write (en handling er en endring)
Terraform som styrer en stack	read og write for hver tjeneste i stacken — en plan leser før den endrer noe
Lese fakturaer for regnskap	billing:read

To vaner holder nøkler trygge: gi en nøkkel én oppgave i stedet for å gjenbruke en bred nøkkel, og sett en utløpsdato slik at en glemt nøkkel slutter å virke av seg selv.

Eksempler

CLI

# Se hva du kan gi, opprett så nøkkelen
fm account api-key scopes
fm account api-key create --name "ci-deploy" \
  --scopes compute:read,compute:write \
  --expires 2027-01-01

Terraform

data "frostmoln_api_key_scopes" "all" {}

resource "frostmoln_api_key" "ci" {
  name   = "ci-deploy"
  scopes = ["compute:read", "compute:write"]
}

Selve nøkkelen vises én gang, ved opprettelsen. Legg den i hemmelighetshåndteringen med en gang — den kan ikke hentes senere, bare erstattes.

Når tilganger ikke er nok

Tilganger sier hvilken type kall en nøkkel får gjøre, aldri på hvilken ressurs eller hvorfra. Når du trenger "kan opprette instanser, men aldri slette dem", "bare i én region", "bare fra kontornettet", eller et eksplisitt avslag, bruk en tilgangspolicy. Det er der de finkornede service:resource:action-operasjonene gjelder, og en policy knyttes til de samme API-nøklene.