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

För nästan varje tjänst är read och write de två åtgärder som API:et upprätthåller (sessionsbehörigheterna är en egen klass — se nedan). 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 flesta övriga verben i katalogen (action, create, update, delete, list): de kan ges, men tjänsterna kontrollerar :read och :write. Ge dem.

Sessionsbehörigheterna är en klass för sig. sessions:forward, sessions:pty och sessions:write är verkliga behörighetssträngar, eftersom en session är ett eget privilegium snarare än en åtgärd på resursen den når. Inget annat träder i deras ställe: compute:action är inte behörigheten som öppnar en terminal på en instans, och kubernetes:* är inte den som öppnar kluster-API-proxyn. Ge dem till varje nyckel som kör fm forward, fm database <type> console, fm shell eller fm kubernetes cluster proxy.

De kontrolleras när nyckeln skapas: du kan inte ge en nyckel en behörighet som din egen roll saknar, så sessions:pty kräver rollen Owner, Administrator, Developer eller Member. De kontrolleras ännu inte när en session öppnas — i dag kan en nyckel som saknar dem ändå öppna en. Ge dem redan nu, så att dina nycklar är rätt när den kontrollen träder i kraft.

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 kräver en inloggad person, inte en nyckel. Att radera en organisation, ändra en medlems roll, ta bort en medlem, lämna en organisation och överföra ägarskap nekas för alla API-nycklar, oavsett vad nyckeln är begränsad till — även *. En nyckel med organizations:write får USER_SESSION_REQUIRED; en nyckel utan den får insufficient_scope först. Gör det i portalen när du är inloggad. Att lämna finns inte i portalen än, så be en administratör eller ägaren att ta bort dig (en administratör måste be ägaren); en ägare måste först överföra ägarskapet och sedan be den nya ägaren. Andra ändringar på organisationsnivå, till exempel att bjuda in medlemmar, kräver organizations:write på nyckeln och en organisationsroll som tillåter dem.
• En nyckel når bara en organisation: den som äger dess tenant. Även om du är medlem i flera organisationer kan en nyckel som skapats i en tenant i den ena inte läsa eller ändra en annan. Listar du organisationer med nyckeln visas bara den ena, och alla andra organisationer nekas med ORGANIZATION_ACCESS_DENIED. Skapa en nyckel i en tenant i varje organisation du automatiserar.
• De flesta fm tenant-kommandon kräver organizations:read. Att lista tenanter, byta med fm tenant use och läsa standardtaggar med fm tenant default-tags get kräver organizations:read. Att skapa eller byta namn på en tenant, eller ändra dess standardtaggar, kräver organizations:write, och att skapa en utan --organization kräver dessutom organizations:read. fm tenant current kräver ingen av dem. Varken fm eller portalen kan ändra behörigheterna för en befintlig nyckel (Terraform-resursen frostmoln_api_key kan uppdatera en nyckel den har skapat): skapa en ny nyckel, byt till den med fm auth api-key set och återkalla sedan den gamla med fm account api-key revoke.
• Kvotförfrågningar kräver quotas:write. Att skicka eller avbryta en förfrågan med fm tenant quota request kräver quotas:write, och att lista förfrågningar kräver quotas:read. compute:write och compute:* räcker inte: en godkänd höjning för en tenant höjer ett kostnadstak, och det är en annan behörighet än att skapa resurser. Befintliga nycklar har inte fått den nya behörigheten, så automation som skickar kvotförfrågningar behöver en ny nyckel med quotas:write. En workload identity kan ha quotas:read men aldrig quotas:write. Att läsa själva kvoterna (fm tenant quota, datakällan frostmoln_tenant_quotas) kräver ingen av dem.

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
Begära kvotändringar	quotas:read, quotas:write

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.