IAM-käyttöoikeuskäytännöt

Käyttöoikeuskäytäntö myöntää tai epää koneprincipaalille — API-avaimelle tai Workload Identity -sidokselle — oikeuden kutsua Frostmoln-rajapintaa. Se on Frostmolnin vastine AWS IAM -käytännölle, GCP IAM:lle tai Azure RBAC:lle, mutta kirjoitettuna Frostmolnin omalla sanastolla.

Käytännöllä voit ilmaista vähimmät oikeudet, joita litteä scope-lista ei pysty: yksittäisen toiminnon koko compute:write -oikeuden sijaan, yhden resurssin, lähde-IP-alueen, aikaikkunan — ja eksplisiittisen epäämisen. Esimerkiksi: CI-avain, joka saa luoda instansseja mutta ei koskaan poistaa niitä; Terraform-avain, joka toimii vain toimistoverkostasi; SDK-avain, joka saa koskea vain resursseihin, joilla on tunniste env=staging.

Ihmiset saavat oikeutensa organisaation rooleista — katso Organisaation jäsenet & roolit neljästä roolista, omistajuudesta ja siitä, miten vuokraajat, ryhmät ja guardrailit yhdistyvät. Tämä sivu käsittelee konepuolta.

Kuka laatii käytäntöjä

Käyttöoikeuskäytännöt hallitsevat koneprincipaaleja, mutta niitä laatii ihminen, joka on kirjautunut sisään OIDC:llä (portaali, fm-komentorivi fm login -kirjautumisen jälkeen tai Terraform OIDC-taustaisella palveluntarjoajalla). API-avain tai workload-identity-token ei voi luoda, muuttaa tai liittää käytäntöä — hallintatasoa ei voi koskaan lukita ulos käytännöllä, jonka alainen se on. Tämä on tarkoituksellista: jopa oman avaimesi deny * -käytännöstä voi palautua, koska korjaat sen ihmisenä.

Miten arviointi toimii

Arviointi on oletuksena epäävä (default-deny):

Jos jokin deny-sääntö täsmää, pyyntö evätään — eksplisiittinen epääminen voittaa aina, riippumatta sääntöjen järjestyksestä tai siitä, mistä käytännöstä se tuli.
Muutoin, jos jokin allow-sääntö täsmää, pyyntö sallitaan.
Muutoin pyyntö evätään (implisiittinen epääminen).

Pyyntö täsmää sääntöön, kun sen toiminto täsmää johonkin säännön operations-arvoista, sen kohde-FRN täsmää johonkin säännön targets-arvoista ja kaikki säännön constraints-ehdot pitävät paikkansa.

Käytäntödokumentti

Käytäntö on JSON-dokumentti: schemaVersion ja lista rules.

json

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

Jokaisella säännöllä on nämä kentät:

Kenttä	Pakollinen	Arvo
`name`	ei	Ihmisluettava nimi säännölle. Vapaata tekstiä; ei vaikuta arviointiin.
`access`	kyllä	`allow` tai `deny`.
`operations`	kyllä	Ei-tyhjä lista toimintomalleja (ks. Toiminnot).
`targets`	kyllä	Ei-tyhjä lista FRN-malleja (ks. Kohteet — FRN).
`constraints`	ei	Lisäehdot, joiden on pidettävä paikkansa (ks. Ehdot).

schemaVersion on merkkijono "1". Skeema on vain lisättävä (append-only) ja versioitu kuten muukin alustan sopimus — uusia ominaisuuksia lisätään, ei koskaan nimetä uudelleen tai poisteta, joten tänään kirjoittamasi käytäntö toimii jatkossakin.

Toiminnot

Toiminto nimeää yhden toiminnan muodossa service:resource:action, esimerkiksi compute:instances:create tai storage:volumes:delete. Jokainen segmentti hyväksyy *-jokerimerkin, ja jokerimerkit tiivistyvät kullakin tasolla:

compute:instances:create — yksi tarkka toiminto
compute:instances:* — jokainen compute-instanssien toiminta
compute:* — jokainen compute-toiminto
*:*:delete — jokainen poisto kaikissa palveluissa

Konkreettisten toimintojen joukko on palvelimen omistama, vain lisättävä luettelo — älä koodaa sitä kovakoodauksena, koska se kasvaa ajan myötä. Hae ajantasainen luettelo:

bash

fm iam catalog                 # all operations
fm iam catalog --filter compute   # only those containing "compute"

tai HTTP:n kautta:

bash

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

Portaalin käytäntörakentaja esittää saman luettelon valitsimena.

Kohteet — FRN

Kohteet täsmätään Frostmoln-resurssinimeen (FRN) — alustan resurssien nimeämismalliin, joka vastaa AWS ARN:ää:

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

Säännön targets-kenttään kirjoitat FRN-malleja käyttäen *-merkkiä minkä tahansa segmentin jokerointiin:

* — täsmää jokaiseen resurssiin (käytä säästeliäästi)
frn:compute:*:*:instances/* — mikä tahansa compute-instanssi, tämän tenantin
frn:storage:*:*:volumes/* — mikä tahansa volyymi, tämän tenantin
frn:compute:*:*:instances/i-0a1b2c3d — yksi tietty instanssi

<region>-segmentin on oltava *

Aluekohtaisia käytäntöjä ei tueta vielä: pyyntö ei kanna mukanaan ratkaistua aluetta, joten aluetta nimeävää kohdetta ei voi täsmätä luotettavasti. Kirjoita siihen aina * — kohde, jossa on jotain muuta, hylätään käytäntöä tallennettaessa. Kaikki muut segmentit toimivat yllä kuvatulla tavalla.

<tenant>-segmentti on sinun tenantisi

Jätä <tenant> arvoon *: koska jokainen pyyntö kantaa mukanaan oman tenantisi, * viittaa jo sinun tenantiisi eikä mihinkään muuhun. Voit myös kirjoittaa oman tenant-tunnuksesi eksplisiittisesti, mutta toista tenantia nimeävä kohde hylätään tallennettaessa — se ei voisi koskaan täsmätä, joten säännöllä ei olisi mitään vaikutusta.

Ehdot

Ehdot lisäävät sääntöön edellytyksiä. Säännön constraints on kartta, jonka avaimena on ensin operaattori ja sitten ehtoavain:

json

{
  "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" }
  }
}

Ehtoavaimet

Avain	Merkitys
`frn:region`	Ei vielä käytettävissä. Pyyntö ei kanna mukanaan ratkaistua aluetta, joten avain ei koskaan ratkea: sitä käyttävä `allow` ei myönnä koskaan, ja sitä käyttävä `deny` laukeaa jokaisella alueella. Jätä se pois.
`frn:sourceIp`	Kutsujan lähde-IP.
`frn:tenant`	Tenantin tunnus.
`frn:principalType`	Principaalin tyyppi: `api_key` tai `workload_identity`.
`frn:currentTime`	Pyynnön ajankohta (`before`/`after`-operaattoreille).
`frn:requestTag/<k>`	Pyyntötunnisteen `<k>` arvo.
`frn:resourceTag/<k>`	Kohderesurssin tunnisteen `<k>` arvo.

Operaattorit ja arvomuodot

Operaattori	Arvomuoto	Huomiot
`equals`	yksittäinen merkkijono	Tarkka täsmäys.
`notEquals`	yksittäinen merkkijono	Negatoitu tarkka täsmäys.
`like`	yksittäinen merkkijono	Glob-täsmäys (`*`-jokerimerkki).
`ipInRange`	lista CIDR-merkkijonoja	Käytetään `frn:sourceIp`-avaimen kanssa.
`before`	yksittäinen RFC3339-aikaleima	Käytetään `frn:currentTime`-avaimen kanssa.
`after`	yksittäinen RFC3339-aikaleima	Käytetään `frn:currentTime`-avaimen kanssa.

ipInRange on ainoa operaattori, joka ottaa listan; jokainen muu operaattori ottaa yksittäisen skalaarimerkkijonon. Tuntematon avain tai operaattori, tai arvo, jota ehto ei pysty ratkaisemaan pyyntöhetkellä, epäonnistuu turvallisesti (fail closed) — ehto ei pidä paikkaansa (joten allow ei myönnä), ja deny laukeaa silti.

⚠️ `deny`-säännön ehto kaventaa sitä

Tämä on tärkein asia ymmärtää oikein. Ehtoja sovelletaan samalla tavalla allow- ja deny-sääntöihin: sääntö täsmää vain, kun sen ehdot pitävät paikkansa. Niinpä deny-säännön ehto saa epäämisen laukeamaan vain silloin, kun ehto on varmasti tosi — jolloin toiminto jää sallituksi aina kun ehto on varmasti epätosi. (Ratkaisematon tai tuntematon ehto laukaisee epäämisen silti — fail-closed.)

Kieltääksesi toiminnon ehdottomasti kirjoita deny-sääntö ilman ehtoa.
Rajoittaaksesi myöntöä (lähde-IP:hen, aikaikkunaan, resurssitunnisteeseen) aseta ehto allow-sääntöön.

json

{
  "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 on verkkorajoitettu ehtonsa perusteella; deny on ehdoton, joten poisto on aina kielletty. Ehto tuossa deny-säännössä olisi sallinut poistot aina, kun ehto oli epätosi.

Käytännön laatiminen

Laadi käytäntö portaalissa, fm-komentorivillä tai Terraformilla. Käytäntö kirjoitetaan kerran ja liitetään sitten yhteen tai useampaan principaaliin.

Portaali

Avaa IAM → Käyttöoikeuskäytännöt, valitse Uusi käytäntö ja käytä opastettua rakentajaa — valitse toiminnot luettelosta, lisää kohteet ja ehdot ja tarkista pyyntö ennen tallennusta sisäänrakennetulla testerillä. Avaa sitten principaali (API-avain tai workload identity) ja liitä käytäntö.

fm CLI

bash

# Create from a file, stdin, or 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 -

# List / inspect / update / delete
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>

# Attach to a 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

Kokoa dokumentti frostmoln_iam_policy_document -datalähteellä (natiivi sanasto — rule / access / operations / targets / constraint), luo sitten käytäntö ja liitä se:

hcl

data "frostmoln_iam_policy_document" "ci" {
  # Restrict the grant with a constraint on the ALLOW rule.
  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"]
    }
  }

  # Forbid delete unconditionally — a deny with NO constraint.
  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 ottaa listan CIDR-osoitteita; jokaisen muun operaattorin values on yksittäinen elementti. Datalähde hylkää moniarvoisen listan minkä tahansa muun operaattorin kohdalla.

Ryhmät

Liittääksesi saman käytännön useaan principaaliin luo ryhmä, lisää siihen principaalit ja liitä käytäntö ryhmään:

bash

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>

Jäsen on api_key tai workload_identity; käytäntö liitetään api_key-, workload_identity- tai group-kohteeseen.

Jos haluat antaa samat käytännöt avaimien sijaan ihmisille, katso Jäsenryhmät alla.

Jäsenryhmät

Yllä olevat ryhmät kokoavat konepääkäyttäjiä. Jäsenryhmät kokoavat ihmisiä: päivystysryhmä tai tietovastaavien tiimi voidaan ottaa käyttöön niin, että ryhmä perii mahdollisimman vähäiset oikeudet, sen sijaan että jokaiselle luotaisiin oma räätälöity rooli. Ne puhuvat samaa sanastoa kuin jokainen tämän sivun käyttöoikeuskäytäntö — toiminnot, FRN-kohteet, ehdot — ja ne liittävät sammat jaetut käytäntödokumentit, joita yllä olevat koneryhmät käyttävät.

Kirjataan, ei vielä täytäntöönpanna henkilöille

Jäsenryhmät kuuluvat koko organisaatiolle eivätkä yksittäiselle tenantille: organisaation omistaja tai ylläpitäjä hallinnoi niitä.

Tässä julkaisussa jäsenryhmään liitetyt käytännöt tallennetaan, mutta niitä ei vielä oteta huomioon, kun ihmisen pyyntöä arvioidaan — mikään niistä ei vielä anna mitään ihmisille. Jäsenet säilyttävät täsmälleen sen, mitä heidän organisaatioroolinsa antaa, kunnes käyttöoikeuskäytäntöjen arviointia ihmisille otetaan käyttöön koko alustalla; ryhmänsä nyt luovat saavat nämä myönnöt voimaan sen kytkimen mukana. Tämä ei koske konepääkäyttäjiä: API-avainten ja työkuormaidentiteettien käyttöoikeuskäytännöt arvioidaan jo tämän sivun kuvauksen mukaan.

Löydät ne kohdasta Organisaatiot → organisaatiosi → Jäsenryhmät:

Luo ryhmä — nimi (yksilöllinen organisaation sisällä) ja valinnainen kuvaus. Nimeä ei voi vielä muuttaa portaalista; poista ryhmä ja luo se uudelleen, jos tarvitset toisen nimen.
Lisää jäseniä — valitse organisaation rosterista. Mikä tahansa ylläpitäjä voi lisätä tai poistaa minkä tahansa jäsenen, omistaja mukaan lukien; kukaan ei voi lisätä itseään (portaali piilottaa nykyisen käyttäjän, ja API hylkää yrityksen siitä huolimatta).
Liitä jaettuja käyttöoikeuskäytäntöjä — valitse organisaation tenantteihin laadituista jaetuista käytännöistä; saat irrottaa käytännön koska tahansa. Ryhmän jäsenet on asetettu perimään kaiken, mitä nämä käytännöt sallivat, sen päälle, mitä heidän organisaatioroolinsa jo antaa — katso alta, mikä saa vaikutuksen tässä julkaisussa. (fm ja Terraform eivät vielä voi laatia jäsenryhmiä; portaali on laatimispinta.)

Mitä jäsenryhmät merkitsevät jäsenille

Ryhmät vain lisäävät — ne eivät koskaan vähennä. Jäsen säilyttää roolinsa oikeudet, ja jokaista liitettyä käytäntöä arvioidaan roolin päällä, ei sen sijaan. Mikään jäsenryhmän asetus ei poista jäsenen roolin oikeuksia.
Ei jäsenryhmän kieltämistä v1:ssä. Jäsenryhmään liitetyn käytännön deny-sääntö ei rajoita ihmisiä, eikä tässä julkaisussa näiden käytäntöjen allow-säännöt anna mitään ihmisillekään — mikään jäsenryhmään liitetty ei vielä vaikuta ihmisten arviointiin. Kun peritty oikeus otetaan käyttöön, jäsenryhmät myöntävät vain lisäten; kieltosäännöt pysyvät konepääkäyttäjäkysymyksenä myöhempään julkaisuun asti. (API-avainten ja työkuormaidentiteettien käytäntöjen kieltosäännöt ovat jo nyt voimassa.)
Ei suoritusaikaista kattoa. Jos kaksi liitettyä käytäntöä mahdollistaa saman toimenpiteen, jäsenellä on se; ei ole suoritusaikaista tarkistusta muotoa ”ryhmä ei saa koskaan ylittää liittäneen ylläpitäjän oikeuksia”. Suoja on per dokumentti liitoshetkellä: liitos, joka ylittää liittävän ylläpitäjän omat oikeudet, hylätään.
Ei mitään sovellettavaa. Portaalissa ei ole sovita- eikä pakota-painiketta — alusta päättää, milloin peritty oikeus saa vaikutuksen, ja (kun se on ihmisten osalta käytössä) muutos saapuu jäsenelle tämän seuraavassa tokenin validoinnissa: viimeistään nykyisen istunnon seuraavassa tokenin uusinnassa.
Jäsenyys on pysyvä. Jäsenyys säilyy roolimuutoksissa ja keskeytyksissä: muutat jonkun organisaatioroolia, ja hänen ryhmäjäsenyytensä säilyy. (Keskeytetty jäsen ei saa mitään oikeuksia keskeytyksen aikana riippumatta ryhmistään — mutta rivi jää listaan, joten käy se läpi roolin alentamisen tai keskeytyksen yhteydessä.) Organisaatiosta poistaminen katkaisee myös käyttöoikeuden.
Ryhmän poistaminen poistaa tallennetun jäsenyyden ja käytäntöliitokset kaikilta sen jäseniltä — jäsenyydet poistetaan kaskadina ja liitokset irrotetaan, joten kun peritty oikeus on käytössä, sen jäsenet menettävät välittömästi, mitä ryhmä oli myöntänyt.

Suojasäännöt

Jäsenryhmät lisäävät oikeuksia; suojasäännöt poistavat ne pöydältä. Suojasääntö kiinnittää vain kieltosääntöjä sisältävän käytännön organisaation tasolle — tai organisaation yksikkörakenteen yhteen yksikköön — ja sen kieltosäännöt sitovat sitten kaikki kiinnityskohdan alapuolella, omistajan mukaan lukien. Tämä on se pohjamuoto, jota yrityksen hallinto pyytää: "mikään rooli, myöntö tai ryhmämuutos ei anna kenenkään lukea näitä resursseja tai poistaa näitä palveluja." Vain alustan oma henkilökunta ohittaa suojasäännön, suunnitellen.

Kirjatut radat, eivät vielä täytäntöönpano henkilöille

Suojasäännöt jakavat jäsenryhmien asennon: ne liitetään ja tallennetaan tänään, ja sen, mitä suojasääntö tekee henkilön pyynnöille, seuraa sama alustanlaajuisesti kytkettävä toiminto, joka käynnistää pääsysääntöjen arvioinnin henkilöille — sama, jota jäsenryhmäosio yllä odottaa. Ennen kuin se kääntyy ympäristössäsi, liitetty suojasääntö ei muuta mitään kenenkään osalta; kun se kääntyy, kielto astuu voimaan jäsenen seuraavassa tokenin validoinnissa. Koneperiaatteet (API-avaimet, työidentiteetit) eivät koskaan joudu suojasääntöjen sidonnaisuuteen — tämä on henkilöakseli.

Löydät ne kohdasta Organisaatiot → organisaatiosi → Suojasäännöt (sama omistaja-tai-ylläpitäjä-kynnys kuin jäsenryhmissä):

Liitä suojasääntö — valitse laajuus (Organisaatio sitoo kaikki; yksikkö sitoo kaiken sen haaraan yksikköpuussa) ja kiinnitä käytäntö, joka sisältää vain kieltosääntöjä. Sallintarivejä sisältävä asiakirja hylätään — suojasääntö ei saa koskaan hiljaa myöntää.
Irrota — ainoa hyväksytty tapa poistaa pohja. Se auditoidaan toimijan nimellä, ja jäsenten tokenit ratkaistaan ilman sitä seuraavassa validoinnissa.

Mitä suojasäännöt tarkoittavat käytännössä

Kielto voittaa, piste. Suojasäännön kielto ylittää ryhmäkäytännöt, omat roolit, esiasetetut roolit ja luo pääsyn. Omistajan kattava * ei anna mitään, minkä suojasääntö kieltää.
Kirjoittaminen kieltää ristiriidat ennen kuin ne ovat olemassa. Alusta hylkää (GUARDRAIL_CONFLICT) suojasäännön, joka menee päällekkäin sen kanssa, mitä organisaatio on jo myöntänyt ryhmän tai oman roolin kautta — ja hylkää toiseen suuntaan ryhmäliitoksen tai roolimuokkauksen, jotka törmäisivät voimassa olevaan suojasääntöön. Hylkäys nimeää operaation; myönnön kaventaminen (tai suojasäännön irrottaminen, mikä itse auditoidaan) on paluutie. Alusta on tässä tahallisesti liian varovainen: yhtä tarkkaan resurssiin kiinnitetty kielto voi hylätä laajemman myönnön samassa perheessä, kunnes jaat asiakirjan.
Kiinnitetty asiakirja on lukittu. Kun käytäntö on kiinnitetty suojasääntönä, sitä ei voi muokata eikä poistaa tavallisen käytäntöpinnan kautta (GUARDRAIL_PINNED) — hiljainen muokkaus olisi hiljainen höllennys. Irrota ensin, muokkaa sitten; yksikkö, johon suojasääntö on kiinnitetty, ei myöskään voi poistaa.
Yksiköt seuraavat kiinnitystään. Yksikköön kiinnitetty suojasääntö tavoittaa jokaisen tenantin sen sisällä — tenantin siirtäminen ei kysy mitään eikä muuta mitään paperilla, mutta mitä sen sitoo seuraavassa tokenvalidoinnissa, sanoo yksikköpuu nyt.
Vain metadata. Suojasäännöt-välilehti näyttää itse kiinnityksen — tason, yksikön, käytännön tunnuksen — ei koskaan käytännön sisältöä; säännöt ovat käytännön omalla pinnalla.

Mukautetut roolit

Neljän kutsun esiasetuksen (viewer, member, billing, admin) lisäksi organisaatio voi kantaa mukautettuja rooleja: nimettyjä oikeusjoukkoja samasta family:action-luettelosta, jota jokainen tämän sivun käyttöoikeuskäytäntö puhuu. Roolit luodaan nykyään rooli-API:lla (POST /tenants/{tenant_id}/roles — portaalin valitsin listaa ne, se ei vielä luo niitä).

Mukautetut roolit kutsujen paikkoina. Kun organisaatiolla on mukautettuja rooleja, kutsuikkunan roolinvalitsin tarjoaa ne esiasteiden rinnalla. Rooliin viitataan sen id:llä, sen on kuuluttava omaan organisaatioon, ja se tarkistetaan uudelleen kutsun hyväksymisen yhteydessä. Kattoa on kaksi:

Ylläpitäjä voi myöntää vain joukon, jonka hän itse kantaa — sekä roolia luotaessa että siihen kutsuttaessa. Myöntäjää laajempi rooli hylätään (ROLE_EXCEEDS_PERMISSIONS).
Omistajan * kattaa kaiken, joten omistaja voi aina osoittaa minkä tahansa organisaation roolin.

Mitä mukautettu rooli merkitsee haltijalleen. Roolin joukko seuraa tokenia samalla tavalla kuin esiasetuksen joukko. Siellä missä ihmisten arviointi on kytketty päälle — sama alustan kytkin, jota yllä olevat jäsenryhmät odottavat — moottori punnittaa roolin joukon; siihen asti mikään ei muutu heidän resurssikutsuissaan. Mukautetut roolit ovat aina taso 0 hallintatikapuissa: niitä ei voi myöntää eikä muuttaa jäsenhallinnan kautta (vain kutsuvirta sijoittaa kenenkään niihin), mutta sellaisen roolin kantava jäsen on silti täysin tavoitettavissa poistamisen, keskeyttämisen, keskeytyksen purkamisen ja alentamisen osalta — sulkemisverbeillä, joita organisaation ylläpitäjällä jo on.

Testaa ennen tallennusta

Väärin laadittu käytäntö puree toden teolla tuotannossa, joten testaa se ensin. Testeri (portaalin rakentaja tai fm iam simulate) ajaa ehdokasdokumentin kuvitteellista pyyntöä vastaan ja palauttaa allow tai deny — se ei koskaan tallenna tai pakota mitään:

bash

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

Ehtokontekstin liput: --source-ip, --tenant, --principal-type, --request-tag key=value, --resource-tag key=value. Pois jätetty ehtokenttä käsitellään ratkaisemattomana / turvallisesti epäävänä (fail-closed), täsmälleen kuten tuotannossa. (Myös --region on olemassa, mutta frn:region ei ole vielä käytettävissä — ks. Ehtoavaimet.)

Siirtyminen scopeista

Nykyiset API-avaimesi scopet (compute:read, storage:write, …) toimivat edelleen — jokainen vanha scope arvioidaan vastaavana synteettisenä allow-käytäntönä, joten pakotettua siirtymää ei ole lainkaan. compute:read käyttäytyy kuin allow compute-lukutoimintojen (read/list) yli kohteessa frn:compute:*.

Siirrät avaimen todelliseen vähimmäisoikeuksien käytäntöön, kun haluat jotain, mitä scopet eivät pysty ilmaisemaan. Esimerkiksi laajan compute:write -scopen korvaaminen:

compute:write myöntää luonnin ja päivityksen ja poiston jokaiselle compute-resurssille, mistä tahansa. Vähimmäisoikeuksien korvaaja voisi olla:

json

{
  "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": ["*"]
    }
  ]
}

Vaiheet:

Laadi käytäntö (yllä) ja testaa se fm iam simulate -komennolla niitä toimintoja vastaan, joita työkuormasi todella suorittaa.
Liitä se avaimeen.
Kavenna avaimen scopet (käytäntö on additiivinen; sekä synteettinen scope-käytäntö että liittämäsi käytäntö arvioidaan, ja mikä tahansa eksplisiittinen deny voittaa). Poista laaja compute:write -scope, kun liitetty käytäntö kattaa sen, mitä avain tarvitsee.
Aja fm iam simulate uudelleen (tai seuraa avainta portaalissa) varmistaaksesi, että myönnöt ja epäämiset ovat odotustesi mukaisia.

Koska eksplisiittinen deny ohittaa minkä tahansa allow-säännön, yllä oleva never-delete-sääntö pätee, vaikka vanha scope on yhä olemassa — turvallinen tapa tiukentaa avainta ennen kuin poistat sen scopet kokonaan.

Laskenta / Instanssit

DNS

Tietokannat

Kubernetes