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

For nesten hver tjeneste er read og write de to handlingene API-et håndhever (sesjonstilgangene er en egen klasse — se nedenfor). 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 fleste øvrige verbene i katalogen (action, create, update, delete, list): de kan gis, men tjenestene sjekker :read og :write. Gi dem.

Sesjonstilgangene er en klasse for seg. sessions:forward, sessions:pty og sessions:write er reelle tilgangsstrenger, fordi en sesjon er sitt eget privilegium og ikke en handling på ressursen den når. Ingenting annet trer i stedet for dem: compute:action er ikke tilgangen som åpner en terminal på en instans, og kubernetes:* er ikke den som åpner kluster-API-proxyen. Gi dem til hver nøkkel som kjører fm forward, fm database <type> console, fm shell eller fm kubernetes cluster proxy.

De sjekkes når nøkkelen opprettes: du kan ikke gi en nøkkel en tilgang din egen rolle mangler, så sessions:pty krever rollen Owner, Administrator, Developer eller Member. De sjekkes ennå ikke når en sesjon åpnes — i dag kan en nøkkel som mangler dem likevel åpne en. Gi dem nå, så nøklene dine allerede er riktige når den sjekken trer i kraft.

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 krever en innlogget person, ikke en nøkkel. Å slette en organisasjon, endre et medlems rolle, fjerne et medlem, forlate en organisasjon og overføre eierskap avvises for alle API-nøkler, uansett hva nøkkelen er begrenset til — også *. En nøkkel med organizations:write får USER_SESSION_REQUIRED; en nøkkel uten den får insufficient_scope først. Gjør det i portalen mens du er innlogget. Å forlate finnes ikke i portalen ennå, så be en administrator eller eieren om å fjerne deg (en administrator må be eieren); en eier må først overføre eierskapet og deretter be den nye eieren. Andre endringer på organisasjonsnivå, for eksempel å invitere medlemmer, krever organizations:write på nøkkelen og en organisasjonsrolle som tillater dem.
• En nøkkel når én organisasjon: den som eier tenanten dens. Selv om du er medlem av flere organisasjoner, kan en nøkkel opprettet i en tenant i den ene ikke lese eller endre en annen. Lister du organisasjoner med nøkkelen, vises bare den ene, og enhver annen organisasjon avvises med ORGANIZATION_ACCESS_DENIED. Opprett en nøkkel i en tenant i hver organisasjon du automatiserer.
• De fleste fm tenant-kommandoer krever organizations:read. Å liste tenanter, bytte med fm tenant use og lese standardtagger med fm tenant default-tags get krever organizations:read. Å opprette eller gi nytt navn til en tenant, eller endre standardtaggene, krever organizations:write, og å opprette en uten --organization krever i tillegg organizations:read. fm tenant current krever ingen av dem. Verken fm eller portalen kan endre tilgangene til en eksisterende nøkkel (Terraform-ressursen frostmoln_api_key kan oppdatere en nøkkel den har opprettet): opprett en ny nøkkel, bytt til den med fm auth api-key set, og trekk deretter tilbake den gamle med fm account api-key revoke.
• Kvoteforespørsler krever quotas:write. Å sende eller avbryte en forespørsel med fm tenant quota request krever quotas:write, og å liste forespørsler krever quotas:read. compute:write og compute:* gir ikke dette: en godkjent økning for en tenant hever et kostnadstak, og det er en annen tilgang enn å opprette ressurser. Eksisterende nøkler har ikke fått den nye tilgangen, så automatisering som sender kvoteforespørsler, trenger en ny nøkkel med quotas:write. En workload identity kan ha quotas:read, men aldri quotas:write. Å lese selve kvotene (fm tenant quota, datakilden frostmoln_tenant_quotas) krever ingen av dem.

Å 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
Be om kvoteendringer	quotas:read, quotas:write

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.