IAM-adgangspolitikker

En adgangspolitik tildeler eller nægter en maskinprincipal — en API-nøgle eller en Arbejdslastidentitet-binding — tilladelse til at kalde Frostmoln-API'et. Den er Frostmolns modstykke til en AWS IAM-politik, GCP IAM eller Azure RBAC, men skrevet i Frostmolns eget ordforråd.

En politik lader dig udtrykke mindste privilegium, som en flad liste af adgange ikke kan: en enkelt operation i stedet for hele compute:write, én ressource, et kilde-IP-interval, et tidsvindue — og eksplicit nægtelse. For eksempel: en CI-nøgle, der må oprette instanser, men aldrig slette dem; en Terraform-nøgle, der kun virker fra dit kontornetværk; en SDK-nøgle, der kun må røre ressourcer, som er tagget env=staging.

Mennesker får deres rettigheder fra organisationsroller — se Organisationsmedlemmer & roller om de fire roller, ejerskabet og hvordan tenants, grupper og guardrails kombineres. Denne side handler om maskin-sporet.

Hvem skriver politikker

Adgangspolitikker styrer maskinprincipaler, men de skrives af et menneske, der er logget ind med OIDC (portalen, fm-CLI'en efter fm login, eller Terraform med en OIDC-baseret provider). En API-nøgle eller et arbejdslastidentitets-token kan ikke oprette, ændre eller tilknytte en politik — administrationsplanet kan aldrig låses ude af en politik, det selv er underlagt. Det er tilsigtet: selv en deny *-politik på din egen nøgle kan udbedres, fordi du retter den som menneske.

Sådan fungerer evalueringen

Evalueringen er default-deny:

1. Hvis en deny-regel matcher, nægtes anmodningen — en eksplicit nægtelse vinder altid, uanset regelrækkefølge, og uanset hvilken politik den kom fra.
2. Ellers tillades anmodningen, hvis en allow-regel matcher.
3. Ellers nægtes anmodningen (implicit nægtelse).

En anmodning matcher en regel, når dens operation matcher en af reglens operations, dens mål-FRN matcher en af reglens targets, og alle reglens constraints holder.

Politikdokumentet

En politik er et JSON-dokument: en schemaVersion og en liste af rules.

{
  "schemaVersion": "1",
  "rules": [
    {
      "name": "compute-read-only",
      "access": "allow",
      "operations": ["compute:instances:read", "compute:instances:list"],
      "targets": ["frn:compute:*:*:instances/*"]
    }
  ]
}

Hver regel har disse felter:

Felt	Påkrævet	Værdi
name	nej	En læsbar etiket for reglen. Fritekst; påvirker ikke evalueringen.
access	ja	allow eller deny.
operations	ja	Ikke-tom liste af operationsmønstre (se Operationer).
targets	ja	Ikke-tom liste af FRN-mønstre (se Mål — FRN).
constraints	nej	Ekstra betingelser, der skal holde (se Betingelser).

schemaVersion er strengen "1". Skemaet er append-only og versioneret som resten af platformskontrakten — nye funktioner tilføjes, aldrig omdøbes eller fjernes, så en politik, du skriver i dag, bliver ved med at virke.

Operationer

En operation navngiver én handling i formatet service:resource:action, for eksempel compute:instances:create eller storage:volumes:delete. Hvert segment accepterer jokertegnet *, og jokertegn kollapser på hvert niveau:

• compute:instances:create — én præcis operation
• compute:instances:* — enhver handling på compute-instanser
• compute:* — enhver compute-operation
• *:*:delete — enhver sletning, på tværs af alle tjenester

Mængden af konkrete operationer er et serverejet, append-only-katalog — hardkod det ikke, for det vokser med tiden. Hent det aktuelle katalog:

fm iam catalog                 # alle operationer
fm iam catalog --filter compute   # kun dem, der indeholder "compute"

eller over HTTP:

curl -H "Authorization: Bearer $TOKEN" \
  https://api.frostmoln.cloud/api/v1/tenants/$TENANT_ID/iam/catalog
# → { "operations": ["billing:invoices:create", "compute:instances:create", ... ] }

Portalens politikbygger præsenterer det samme katalog som en vælger.

Mål — FRN

Mål matches mod et Frostmoln Resource Name (FRN) — platformens ressourcenavngivningsskema, der svarer til et AWS ARN:

frn:<service>:<region>:<tenant>:<type>/<id>

I en regels targets skriver du FRN-mønstre og bruger * som jokertegn for et vilkårligt segment:

• * — matcher enhver ressource (brug det sparsomt)
• frn:compute:*:*:instances/* — enhver compute-instans, denne tenants
• frn:storage:*:*:volumes/* — ethvert volumen, denne tenants
• frn:compute:*:*:instances/i-0a1b2c3d — én bestemt instans

Segmentet <region> skal være *

Regionsafgrænsede politikker understøttes ikke endnu: anmodninger bærer ingen opslået region, så et mål, der navngiver en, kan ikke matches pålideligt. Skriv altid * der — et mål med noget andet afvises, når du gemmer politikken. Alle øvrige segmenter fungerer som beskrevet ovenfor.

Segmentet <tenant> er din tenant

Lad <tenant> stå som *: fordi enhver anmodning bærer din egen tenant med sig, peger * allerede på din tenant og ingen anden. Du må også skrive dit eget tenant-id eksplicit, men et mål, der navngiver en anden tenant, afvises, når du gemmer — det ville aldrig kunne matche, så reglen ville stiltiende ikke have nogen effekt.

Betingelser

Betingelser føjer forudsætninger til en regel. En regels constraints er et map, der er nøglet på operator og derefter på betingelsesnøgle:

{
  "name": "read-staging-from-office",
  "access": "allow",
  "operations": ["compute:instances:read"],
  "targets": ["frn:compute:*:*:instances/*"],
  "constraints": {
    "ipInRange": { "frn:sourceIp": ["203.0.113.0/24"] },
    "equals": { "frn:resourceTag/env": "staging" }
  }
}

Betingelsesnøgler

Nøgle	Betydning
frn:region	Kan ikke bruges endnu. Anmodninger bærer ingen opslået region, så denne nøgle kan aldrig opslås: et allow, der bruger den, tildeler aldrig, og et deny, der bruger den, udløses overalt. Lad den være.
frn:sourceIp	Kalderens kilde-IP.
frn:tenant	Tenant-id'et.
frn:principalType	Principalens type: api_key eller workload_identity.
frn:currentTime	Anmodningens tidspunkt (til before/after).
frn:requestTag/<k>	Værdien af anmodningstagget <k>.
frn:resourceTag/<k>	Værdien af tagget <k> på målressourcen.

Operatorer og værdiformer

Operator	Værdiform	Noter
equals	en enkelt streng	Præcis match.
notEquals	en enkelt streng	Negeret præcis match.
like	en enkelt streng	Glob-match (jokertegnet *).
ipInRange	en liste af CIDR-strenge	Bruges med frn:sourceIp.
before	et enkelt RFC3339-tidsstempel	Bruges med frn:currentTime.
after	et enkelt RFC3339-tidsstempel	Bruges med frn:currentTime.

ipInRange er den eneste operator, der tager en liste; enhver anden operator tager en enkelt skalar streng. En ukendt nøgle eller operator, eller en værdi, som en betingelse ikke kan opslå på anmodningstidspunktet, fejler lukket — betingelsen holder ikke (så et allow tildeler ikke), og et deny udløses stadig.

⚠️ En betingelse på et deny indsnævrer det

Dette er det enkeltstående vigtigste at få rigtigt. Betingelser anvendes på samme måde på allow- og deny-regler: en regel matcher kun, når dens betingelser holder. Så en betingelse på en deny-regel gør, at nægtelsen kun udløses, når betingelsen er definitivt sand — hvilket efterlader operationen tilladt, når betingelsen er definitivt falsk. (En uopslået eller ukendt betingelse udløser stadig nægtelsen — fail-closed.)

• For at forbyde en operation ubetinget skal du skrive en deny-regel uden betingelse.
• For at begrænse en tildeling (til et kilde-IP, et tidsvindue, et ressourcetag) skal du lægge betingelsen på allow-reglen.

{
  "schemaVersion": "1",
  "rules": [
    {
      "name": "create-read-from-office",
      "access": "allow",
      "operations": ["compute:instances:create", "compute:instances:read"],
      "targets": ["frn:compute:*:*:instances/*"],
      "constraints": { "ipInRange": { "frn:sourceIp": ["203.0.113.0/24"] } }
    },
    {
      "name": "never-delete",
      "access": "deny",
      "operations": ["compute:instances:delete"],
      "targets": ["*"]
    }
  ]
}

allow er netværksbegrænset af sin betingelse; deny er ubetinget, så sletning er forbudt altid. En betingelse på det deny ville have tilladt sletninger, hver gang betingelsen var falsk.

Sådan skriver du en politik

Skriv den i portalen, med fm-CLI'en eller med Terraform. En politik skrives én gang og tilknyttes derefter en eller flere principaler.

Portal

Åbn IAM → Adgangspolitikker, vælg Ny politik, og brug den guidede bygger — vælg operationer fra kataloget, tilføj mål og betingelser, og brug den indbyggede tester til at kontrollere en anmodning, inden du gemmer. Åbn derefter en principal (API-nøgle eller arbejdslastidentitet), og tilknyt politikken.

fm CLI

# Opret fra en fil, fra stdin eller som inline JSON
fm iam policy create --name ci-compute-operator --document @policy.json
cat policy.json | fm iam policy create --name ci-compute-operator --document -

# Vis / inspicér / opdater / slet
fm iam policy list
fm iam policy get <policy-id>
fm iam policy update <policy-id> --document @policy.json
fm iam policy delete <policy-id>

# Tilknyt til en principal (api_key | workload_identity | group)
fm iam policy attach <policy-id> --type api_key --id <key-id>
fm iam policy detach <policy-id> --type api_key --id <key-id>

Terraform

Sammensæt dokumentet med datakilden frostmoln_iam_policy_document (eget ordforråd — rule / access / operations / targets / constraint), og opret derefter politikken, og tilknyt den:

data "frostmoln_iam_policy_document" "ci" {
  # Begræns tildelingen med en betingelse på ALLOW-reglen.
  rule {
    name       = "create-read-from-office"
    access     = "allow"
    operations = ["compute:instances:create", "compute:instances:read"]
    targets    = ["frn:compute:*:*:instances/*"]

    constraint {
      operator = "ipInRange"
      key      = "frn:sourceIp"
      values   = ["203.0.113.0/24"]
    }
  }

  # Forbyd sletning ubetinget — et deny UDEN betingelse.
  rule {
    name       = "never-delete"
    access     = "deny"
    operations = ["compute:instances:delete"]
    targets    = ["*"]
  }
}

resource "frostmoln_iam_policy" "ci" {
  name        = "ci-compute-operator"
  description = "CI: create/read compute from the office network, never delete"
  document    = data.frostmoln_iam_policy_document.ci.json
}

resource "frostmoln_iam_policy_attachment" "ci_key" {
  policy_id     = frostmoln_iam_policy.ci.id
  attachee_type = "api_key" # or "workload_identity" / "group"
  attachee_id   = frostmoln_api_key.ci.id
}

ipInRange tager en liste af CIDR'er; enhver anden operators values er ét enkelt element. Datakilden afviser en liste med flere værdier på enhver anden operator.

Grupper

For at tilknytte den samme politik til flere principaler skal du oprette en gruppe, føje principaler til den og tilknytte politikken til gruppen:

fm iam group create --name ci-keys
fm iam group member add <group-id> --type api_key --id <key-id>
fm iam policy attach <policy-id> --type group --id <group-id>

Et medlem er en api_key eller en workload_identity; en politik tilknyttes en api_key, en workload_identity eller en group.

For at give de samme politikker til mennesker i stedet for nøgler, se Medlemsgrupper nedenfor.

Medlemsgrupper

Grupperne ovenfor samler maskineprincipaler. Medlemsgrupper samler mennesker: en beredskabsgruppe eller et team af dataforvaltere kan sættes op til at arve minimal-privilegie-tilladelser som gruppe, i stedet for at oprette en skræddersyet rolle pr. person. De taler det samme ordforråd som alle adgangspolitikker på denne side — operationer, FRN-mål, betingelser — og de tilknytter de samme delte politikdokumenter, som maskinegrupperne ovenfor bruger.

Registreret, endnu ikke håndhævet for mennesker

Medlemsgrupper hører til hele organisationen i stedet for til én tenant: en organisations ejer eller administrator administrerer dem.

I denne udgivelse registreres de politikker, du tilknytter en medlemsgruppe, men de inddrages endnu ikke, når en persons forespørgsler vurderes — intet i dem får effekt for mennesker endnu. Medlemmerne beholder præcis, hvad deres organisationsrolle giver, indtil adgangspolitikvurderingen for mennesker slås til for hele platformen; opretter du grupperne nu, går disse tildelinger live med den kontakt. Maskineprincipaler påvirkes ikke af dette: adgangspolitikker på API-nøgler og arbejdsbelastningsidentiteter vurderes allerede som beskrevet på denne side.

Du finder dem under Organisationer → din organisation → Medlemsgrupper:

1. Opret en gruppe — et navn (unikt inden for organisationen) og en valgfri beskrivelse. Navne kan ikke redigeres fra portalen endnu; slet gruppen og opret den igen, hvis du har brug for et andet.
2. Tilføj medlemmer — vælg fra organisationens medlemsliste. Enhver administrator kan tilføje eller fjerne ethvert medlem, ejeren inkluderet; ingen kan tilføje sig selv (portalen skjuler den aktuelle bruger, og API'et afviser forsøget alligevel).
3. Tilknyt delte adgangspolitikker — vælg blandt de delte politikker, der er udarbejdet i organisationens tenants; du kan fjerne en tilknytning når som helst. Gruppens medlemmer er sat op til at arve alt, hvad disse politikker tillader, ud over, hvad deres organisationsrolle allerede giver — se nedenfor, hvad der får effekt i denne udgivelse. (fm og Terraform kan endnu ikke udarbejde medlemsgrupper; portalen er udarbejdelsesfladen.)

Hvad medlemsgrupper betyder for medlemmerne

• Grupper tilføjer kun — de fjerner aldrig. Et medlem beholder sin rolles rettigheder, og hver tilknyttet politik vurderes oven på rollen, aldrig i stedet for den. Der findes ingen indstilling for medlemsgrupper, der fjerner et medlems rollerettigheder.
• Ingen afvisning fra medlemsgrupper i v1. En deny-regel i en politik, der er tilknyttet en medlemsgruppe, begrænser ikke mennesker, og i denne udgivelse giver disse politikkers allow-regler heller ikke noget til mennesker — intet tilknyttet en medlemsgruppe påvirker vurderingen for mennesker endnu. Når nedarvet autoritet bliver aktiv, tildeler medlemsgrupper kun additivt; udtrykkelige afvisningsregler forbliver et maskineprincipspørgsmål til en senere udgivelse. (Afvisningsregler i politikker for API-nøgler og arbejdsbelastningsidentiteter håndhæves allerede i dag.)
• Intet loft ved kørselstid. Hvis to tilknyttede politikker begge tillader en operation, har et medlem den; der findes ingen kørselstidskontrol i stilen »gruppen må aldrig overstige rettighederne hos den administrator, der tilknyttede den«. Beskyttelsen ligger pr. dokument ved tilknytningstidspunktet: en tilknytning, der overstiger den tilknyttende administrators egne rettigheder, afvises.
• Intet at anvende. Portalen har ingen knap til at anvende eller håndhæve — platformen styrer, hvornår nedarvet autoritet får effekt, og (når den er aktiv for mennesker) når en ændring et medlem ved dets næste tokenvalidering: senest ved den aktuelle sessions næste tokenfornyelse.
• Medlemskabet er holdbart. Medlemskab overlever rolleændringer og suspenderinger: ændrer du en persons organisationsrolle, følger deres gruppemedlemskab med. (Et suspenderet medlem modtager ingen autoritet overhovedet, mens de er suspenderet, uanset hvad deres grupper siger — men rækken forbliver i listen, så gennemgå den ved degradering eller suspendering.) At fjerne nogen fra organisationen lukker også deres adgang.
• At slette en gruppe sletter dens registrerede medlemskab og politiktilknytninger for alle i den — medlemskaber kaskader, og tilknytningerne fjernes, så når nedarvet autoritet er aktiv, mister dens medlemmer straks det, gruppen havde givet.

Vagtregler

Medlemsgrupper tilføjer rettigheder; vagtregler fjerner dem fra bordet. En vagtregel fastgør en politik, der kun indeholder afvisningsregler, på organisationsniveau — eller på én enhed i organisationens enhedsstruktur — og dens afvisningsregler binder derefter alle under tilknytningspunktet, ejeren inkluderet. Det er gulvformen, virksomhedsstyring beder om: "ingen rolle, ingen tildeling, ingen gruppejustering kan lade nogen læse disse ressourcer eller slette disse tjenester." Kun platformens egen personale unddrager sig en vagtregel, af design.

Registrerede baner, endnu ikke håndhævet for mennesker

Vagtregler deler medlemsgruppernes stilling: de tilknyttes og lagres i dag, og hvad en vagtregel gør for en persons kald følger den samme platformsbredte kontakt, der tænder evaluering af adgangspolitikker for mennesker — den samme, som medlemsgrup afsnittet ovenfor venter på. Før den slår om i dit miljø ændrer en tilknyttet vagtregel intet for nogen; når den gør, træder afvisningen i kraft ved medlemmets næste tokenvalidering. Maskineprincipaler (API-nøgler, arbejdsidentiteter) bindes aldrig af vagtregler — dette er en menneskeakse.

Find dem under Organisationer → din organisation → Vagtregler (samme ejer-eller-admin-tærskel som medlemsgrupper):

1. Tilknyt en vagtregel — vælg omfanget (Organisation binder alle; en enhed binder alt i dens gren af enhedstræet) og fastgør en politik, der kun indeholder afvisningsregler. Et dokument med tilladelsesregler afvises — en vagtregel må aldrig lydløst tildele.
2. Frigør — den eneste sanktionerede måde at fjerne et gulv på. Den revideres med aktørens navn, og medlemmernes tokens løses uden den ved næste validering.

Hvad vagtregler betyder i praksis

• Afvisning vinder, punktum. En vagtregels afvisning slår gruppepolitikker, brugerdefinerede roller, forudindstillinger og læseadgang. Ejeren helt dækkende * giver intet, en vagtregel forbyder.
• Forfatteren nægter konflikter, før de findes. Platformen nægter (GUARDRAIL_CONFLICT) en vagtregel, der overlapper noget organisationen allerede har tildelt via en gruppe eller en brugerdefineret rolle — og nægter i den anden retning en gruppetilknytning eller rolle_redigering, der ville kollidere med en stående vagtregel. Afvisningen nævner operationen; at indsnævre tildelingen (eller frigøre vagtreglen, hvilket selv revideres) er vejen tilbage. Platformen er bevidst overforsigtig her: en afvisning fastgjort til én præcis ressource kan nægte en bredere tildeling i samme familie, til du deler dokumentet.
• Det fastgjorte dokument er låst. Mens en politik er tilknyttet som vagtregel, kan den ikke redigeres eller slettes via den almindelige politikflade (GUARDRAIL_PINNED) — en lydløs redigering ville være en lydløs lempelse. Frigør først, rediger derefter; en organisationsenhed med en tilknyttet vagtregel kan heller ikke slettes.
• Enheder følger deres tilknytning. En vagtregel fastgjort til en enhed når hver tenant i den — at flytte en tenant spørger om ingenting og ændrer intet på papir, men det, der binder den ved næste tokenvalidering, er hvad enhedstræet nu siger.
• Kun metadata. Vagtregel-fanen viser selve tilknytningen — niveau, enhed, politik-id — aldrig politikkens indhold; reglerne ligger på policyens egen flade.

Egen designede roller

Ud over de fire invitationsforudindstillinger (viewer, member, billing, admin) kan en organisation bære egen designede roller: navngivne tilladelsessæt fra samme family:action-katalog som alle adgangspolitikker på denne side. Rollerne oprettes i dag via rolle-API'et (POST /tenants/{tenant_id}/roles — portalens vælger viser dem, den opretter dem ikke endnu).

Egen designede roller som invitationspladser. Når organisationen har egne roller, tilbyder invitationsdialogens rollevælger dem ved siden af forudindstillingerne. En rolle refereres til med sit id, skal tilhøre din egen organisation og tjekkes igen, når invitationen accepteres. To lofter beskytter tildelingen:

• En admin kan kun tildele et sæt, de selv har — både ved oprettelse af en rolle og ved invitation til den. En rolle bredere end tildeleren afvises (ROLE_EXCEEDS_PERMISSIONS).
• Ejerens * dækker alt, så en ejer kan altid tildele enhver rolle i organisationen.

Hvad en egen designet rolle betyder for indehaveren. Rollens sæt følger med deres token præcis som en forudindstillings gør. Hvor evaluering for mennesker er slået til — samme platformskontakt som medlemsgrupperne ovenfor venter på — er det rollens sæt, motoren vejer; indtil da ændrer intet sig for deres ressourcekald. Egen designede roller er altid niveau 0 i administrationsstigen: de kan ikke tildeles eller ændres via medlemsadministrationen (kun invitationsflowet placerer nogen i dem), men et medlem med en sådan rolle er stadig fuldt tilgængelig for fjernelse, suspension, genoptagelse og degradering — de indeslutningsverb en organisationsadmin allerede råder over.

Test, inden du gemmer

En forkert skrevet politik har rigtige tænder i produktion, så test den først. Testeren (portalbyggeren eller fm iam simulate) kører et kandidatdokument mod en hypotetisk anmodning og returnerer allow eller deny — den gemmer eller håndhæver aldrig noget:

fm iam simulate --document @policy.json \
  --operation compute:instances:delete --target '*'
# → deny

fm iam simulate --document @policy.json \
  --operation compute:instances:read --target 'frn:compute:*:*:instances/*' \
  --source-ip 203.0.113.10
# → allow

Flag til betingelseskontekst: --source-ip, --tenant, --principal-type, --request-tag key=value, --resource-tag key=value. Et udeladt betingelsesfelt behandles som unresolved / fail-closed, præcis som i produktion. (--region findes også, men frn:region kan ikke bruges endnu — se Betingelsesnøgler.)

Migrering fra adgange

Dine eksisterende adgange på API-nøgler (compute:read, storage:write, …) virker stadig — enhver ældre adgang evalueres som en tilsvarende syntetiseret allow-politik, så der er ingen tvungen migrering overhovedet. compute:read opfører sig som et allow over compute-operationerne read/list på frn:compute:*.

Du migrerer en nøgle til en rigtig politik med mindste privilegium, når du vil have noget, adgange ikke kan udtrykke. For eksempel at erstatte en bred compute:write-adgang:

compute:write tildeler create og update og delete på enhver compute-ressource, fra hvor som helst. En erstatning med mindste privilegium kunne være:

{
  "schemaVersion": "1",
  "rules": [
    {
      "name": "create-and-update-from-office",
      "access": "allow",
      "operations": [
        "compute:instances:create",
        "compute:instances:update",
        "compute:instances:read",
        "compute:instances:list"
      ],
      "targets": ["frn:compute:*:*:instances/*"],
      "constraints": { "ipInRange": { "frn:sourceIp": ["203.0.113.0/24"] } }
    },
    {
      "name": "never-delete",
      "access": "deny",
      "operations": ["compute:instances:delete"],
      "targets": ["*"]
    }
  ]
}

Trin:

1. Skriv politikken (ovenfor), og test den med fm iam simulate mod de operationer, din arbejdslast faktisk udfører.
2. Tilknyt den til nøglen.
3. Indsnævr adgangene på nøglen (politikken er additiv; både den syntetiserede adgangspolitik og din tilknyttede politik evalueres, og enhver eksplicit deny vinder). Fjern den brede compute:write-adgang, når den tilknyttede politik dækker det, nøglen har brug for.
4. Kør fm iam simulate igen (eller følg nøglen i portalen) for at bekræfte, at tildelingerne og nægtelserne er som forventet.

Fordi en eksplicit deny tilsidesætter ethvert allow, holder reglen never-delete ovenfor, selv mens den ældre adgang stadig er til stede — en sikker måde at stramme en nøgle op på, inden du er færdig med at fjerne dens adgange.