API-nyckelbehörigheter

En API-nyckel autentiserar ett program — CI, ett skript, Terraform — mot Frostmoln-API:et. Varje nyckel bär behörigheter (scopes): listan över vad den får göra. Frostmolns nycklar följer minsta möjliga behörighet, så en nyckel gör ingenting förrän du anger vad den får göra.

Listan serveras av plattformen

Det finns ingen fast lista att kopiera från den här sidan. Katalogen ligger i plattformen och motsvarar därför alltid vad som accepteras när en nyckel skapas. Läs den där du arbetar:

Var	Hur
Portalen	Inställningar → API-nycklar → Skapa API-nyckel. Behörighetsväljaren listar varje behörighet med en beskrivning av vad den ger.
CLI	fm account api-key scopes (lägg till -o json för skript).
Terraform	Datakällan frostmoln_api_key_scopes — kör terraform console och sedan data.frostmoln_api_key_scopes.all.scopes.

Så ser en behörighet ut

En behörighet skrivs som <tjänst>:<åtgärd>:

compute:read     läsa compute-resurser
compute:write    skapa, ändra och ta bort dem
storage:read     läsa volymer och buckets
billing:read     läsa fakturor och användning

read och write är de två åtgärder som API:et upprätthåller i dag. write omfattar varje förändring — skapa, uppdatera, ta bort samt åtgärder som start/stopp/omstart. Det finns ingen separat "skapa men inte ta bort"-behörighet: när du behöver den skillnaden, använd en åtkomstpolicy.

Ge read och write, inte de finare formerna

Katalogen listar även tredelade poster som compute:instances:read, och nyckelskapandet accepterar dem. De upprätthålls inte som nyckelbehörigheter — de hör till åtkomstpolicy-motorn. En nyckel som bara har compute:instances:read skapas utan fel och nekas sedan vid varje compute-anrop, med en 403 som inte förklarar varför.

Detsamma gäller de övriga verben i katalogen (action, create, update, delete, list): de kan ges, men tjänsterna kontrollerar :read och :write. Ge dem.

Jokertecken

Behörighet	API-nyckel	Arbetsbelastningsidentitet
* (allt)	Avvisas — WILDCARD_SCOPE_NOT_ALLOWED	Avvisas — WILDCARD_SCOPE_FORBIDDEN
compute:* (en tjänst)	Tillåts	Avvisas — WILDCARD_SCOPE_FORBIDDEN
compute:read	Tillåts	Tillåts

En Workload Identity-bindning är medvetet striktare än en API-nyckel: en federerad pod-behörighet måste namnge exakt vad den behöver.

Observera att compute:* verkligen ger allt den tjänsten erbjuder, nu och i framtiden. Två namngivna behörigheter är nästan alltid ett bättre val.

Regler värda att känna till

• Minst en behörighet krävs. En tom lista avvisas med SCOPES_REQUIRED, och en okänd behörighet med INVALID_SCOPES (när en nyckel skapas; INVALID_SCOPE när en nyckel eller en arbetsbelastningsbindning uppdateras).
• En nyckel kan aldrig överstiga dig — i det ögonblick du skapar den. Behörigheterna begränsas av behörigheterna hos den identitet som skapar nyckeln; att begära mer misslyckas med SCOPE_EXCEEDS_PERMISSIONS. Detta kontrolleras när nyckeln skapas eller dess behörigheter ändras. Om dina egna behörigheter minskas senare behåller redan utfärdade nycklar sina behörigheter — återkalla och utfärda dem på nytt.
• Organisationskontroll styrs inte av behörigheter. Att radera en organisation, ändra medlemmar och överföra ägarskap auktoriseras av din organisationsroll, inte av nyckelns behörigheter — en nyckel skapad av en ägare kan utföra dem oavsett vad den är begränsad till. Betrakta inte en smal behörighetslista som skydd mot förändringar på organisationsnivå: skapa automationsnycklar från ett konto som inte är organisationsägare.

Att välja behörigheter

Utgå från uppgiften nyckeln utför, inte från tjänsten den anropar.

Nyckeln gör detta	Ge
Övervakning / inventering	compute:read, storage:read, network:read — läsningarna för det den inspekterar
CI som driftsätter instanser	compute:read, compute:write
Starta om en tjänst schemalagt	compute:read, compute:write (en åtgärd är en förändring)
Terraform som hanterar en stack	read och write för varje tjänst i stacken — en plan läser innan den ändrar något
Läsa fakturor för bokföring	billing:read

Två vanor håller nycklar säkra: ge en nyckel ett enda uppdrag i stället för att återanvända en bred nyckel, och sätt ett utgångsdatum så att en bortglömd nyckel slutar fungera av sig själv.

Exempel

CLI

# Se vad du kan ge, skapa sedan nyckeln
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"]
}

Själva nyckeln visas en gång, när den skapas. Lägg den i din hemlighetshanterare direkt — den kan inte hämtas i efterhand, bara ersättas.

När behörigheter inte räcker

Behörigheter anger vilken sorts anrop en nyckel får göra, aldrig på vilken resurs eller varifrån. När du behöver "får skapa instanser men aldrig ta bort dem", "bara i en region", "bara från kontorsnätet", eller ett uttryckligt nekande, använd en åtkomstpolicy. Det är där de finkorniga service:resource:action-operationerna gäller, och en policy kopplas till samma API-nycklar.