Työkuormaidentiteetti

Työkuormaidentiteetti (Workload Identity) antaa hallitun Kubernetes-klusterisi podin kutsua Frostmoln-API:a Kubernetes-palvelutilillään — ilman podiin tallennettua pitkäikäistä API-avainta. Se on Frostmolnin vastine AWS IAM Roles for Service Accounts -mallille (IRSA), GCP Workload Identity Federationille ja Azure Workload Identitylle.

Podille luodaan tarvittaessa lyhytikäinen, rajattu Frostmoln-tunnus, joka uusitaan automaattisesti. Mitään salaista ei paisteta imageen tai itse hallinnoimaasi Secret- objektiin.

Pilotti — käyttöoikeus myönnetään vuokralaiskohtaisesti

Työkuormaidentiteetti julkaistaan pilottina. Se on käytettävissä vain vuokralaisille, joilla on workload-identity-oikeus, ja vain tällaisen vuokralaisen hallituissa Kubernetes-klustereissa. Jos et näe klusterissa Työkuormaidentiteetti-välilehteä, sitä ei ole vielä otettu käyttöön vuokralaisellasi — pyydä käyttöoikeutta tuesta.

Miten se toimii

1. Luot sidonnan, joka yhdistää jonkin klusterisi (nimiavaruus, palvelutili) -parin vähimmän oikeuden periaatteen mukaiseen joukkoon Frostmoln-oikeuksia.
2. Merkitset kyseisen Kubernetes-palvelutilin liittymään mukaan annotaatiolla.
3. Kun pod suoritetaan kyseisellä palvelutilillä, klusteri tekee automaattisesti seuraavaa:
   • projisoi lyhytikäisen Kubernetes-palvelutilitunnisteen podiin,
   • suorittaa pienen tunnusapuri-sivukontin, joka vaihtaa sen rajattuun Frostmoln-tunnisteeseen, ja
   • kirjoittaa tunnisteen tiedostoon, jonka sovellus lukee.
4. Sovelluksesi kutsuu Frostmoln-API:a tunnisteella. Se uusitaan automaattisesti ennen vanhenemista (suunnilleen tunnin välein), joten sovellus ei koskaan käsittele pitkäikäistä salaisuutta.

Vaihto on yksisuuntainen ja vain lähtevä: alusta ei koskaan ulotu klusteriisi, ja pod vaihtaa jo hallussaan olevan tunnisteen Frostmoln-tunnisteeseen, johon sillä on oikeus.

Vaihe 1 — Luo sidonta

Sidonta myöntää tietylle palvelutilille tietyn joukon oikeuksia. Ne tulevat joko sidonnan omista oikeuksista tai siihen liitetystä käyttöoikeuskäytännöstä — katso Myöntäminen käyttöoikeuskäytännöllä alta. Luo sidonta portaalissa, fm-komentorivityökalulla tai Terraformilla.

Portaali

Avaa klusterin tietosivulla Työkuormaidentiteetti-välilehti ja valitse Lisää sidonta. Anna nimiavaruus ja palvelutilin nimi, valitse myönnettävät oikeudet ja tallenna.

fm CLI

fm kubernetes workload-identity binding create \
  --cluster <cluster-id> \
  --namespace default \
  --service-account my-app \
  --scope compute:read --scope storage:read

# Listaa ja poista
fm kubernetes workload-identity binding list --cluster <cluster-id>
fm kubernetes workload-identity binding delete <binding-id>

Terraform

resource "frostmoln_workload_identity_binding" "my_app" {
  cluster_id      = frostmoln_kubernetes_cluster.prod.id
  namespace       = "default"
  service_account = "my-app"

  scopes = [
    "compute:read",
    "storage:read",
  ]
}

Vaihe 2 — Merkitse palvelutili annotaatiolla

Ota palvelutili mukaan lisäämällä annotaatio frostmoln.cloud/workload-identity: "true":

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  namespace: default
  annotations:
    frostmoln.cloud/workload-identity: 'true'

tai imperatiivisesti:

kubectl -n default annotate serviceaccount my-app \
  frostmoln.cloud/workload-identity=true

Vain tämän annotaation sisältävät palvelutilit kytketään — se on palvelutilikohtainen mukaanotto.

Vaihe 3 — Käytä tunnusta podissasi

Suorita pod merkityllä palvelutilillä. Alusta injektoi kaiken automaattisesti; sovelluksesi tarvitsee vain lukea tunniste tiedostosta, jonka nimeää ympäristömuuttuja FROSTMOLN_WORKLOAD_CREDENTIALS_FILE, ja lähettää sen bearer-tunnisteena:

curl -H "Authorization: Bearer $(cat "$FROSTMOLN_WORKLOAD_CREDENTIALS_FILE")" \
  https://api.frostmoln.cloud/api/v1/...

token, _ := os.ReadFile(os.Getenv("FROSTMOLN_WORKLOAD_CREDENTIALS_FILE"))
req.Header.Set("Authorization", "Bearer "+strings.TrimSpace(string(token)))

Tiedosto uusitaan paikallaan ennen tunnisteen vanhenemista, joten lue se uudelleen (älä tallenna sen sisältöä välimuistiin) pitkään käynnissä olevissa prosesseissa.

Oikeudet

Työkuormaidentiteetit noudattavat vähimmän oikeuden periaatetta. Sidonnan oikeuksien on oltava eksplisiittisiä ja konkreettisia — jokerimerkit * (kaikki) ja <resurssi>:* (esim. compute:*) hylätään. Myönnä vain oikeudet, joita työkuorma todella tarvitsee, esimerkiksi:

• compute:read — lue instanssit, imaget, flavorit
• storage:read — lue taltiot ja bucketit
• network:read — lue VPC:t, aliverkot, suojausryhmät

Laajentaaksesi tai kaventaaksesi käyttöoikeutta myöhemmin päivitä sidonnan oikeudet — muutos tulee voimaan seuraavassa tunnisteen uusinnassa.

Myöntäminen käyttöoikeuskäytännöllä

Oikeudet ovat karkeita: compute:read antaa lukuoikeuden kaikkiin instansseihin, imageihin ja flavoreihin. Käyttöoikeuskäytäntö voi nimetä yksittäisiä resursseja, lisätä ehtoja kuten lähde-IP-alueen ja kieltää eksplisiittisesti. Työkuormalle, jonka pitää käyttää yhtä bucketia yhdestä verkosta, käytäntö ilmaisee sen mitä oikeus ei voi.

Luo sidonta ilman oikeuksia ja liitä siihen käytäntö.

# Luo sidonta ilman oikeuksia
fm kubernetes workload-identity binding create \
  --cluster <cluster-id> --namespace ops --service-account reaper

# Liitä siihen käytäntö
fm iam policy attach <policy-id> --type workload_identity --id <binding-id>

Portaalissa jätä oikeusvalitsin tyhjäksi sidontaa lisätessäsi ja liitä sitten käytäntö kohdassa Asetukset → Käyttöoikeuskäytännöt. Terraformissa jätä scopes pois ja lisää frostmoln_iam_policy_attachment.

Sidonta ilman oikeuksia näkyy listassa muodossa ei oikeuksia — portaali eikä fm pysty erottamaan liitetyllä käytännöllä myönnettyä sidontaa sellaisesta, joka ei myönnä mitään, joten kumpikaan ei väitä niin. Kolme asiaa on hyvä tietää:

• Se on tehoton, kunnes käytäntö on liitetty. Kun mikään ei myönnä sille mitään, tunnisteenvaihto kieltäytyy luomasta tunnistetta sen sijaan että myöntäisi tunnisteen, joka ei anna mitään — podin tunnusapuri ilmoittaa virheen sen sijaan että saisi kuolleen tunnisteen.
• Sidontaa ei voi koskaan jättää ilman yhtään myönnettyä oikeutta. Sen viimeisen jäljellä olevan myönnön — oikeuksien tai viimeisen käytännön — poistaminen hylätään. Poista sidonta sen sijaan.
• Niin kauan kuin sidonnalla on sekä oikeudet että käytäntö, oikeudet ovat voimassa. Käytännön lisäoikeudet tulevat voimaan vasta kun oikeudet on poistettu, joten varmista poistamisen jälkeen — ei liittämisen jälkeen.

Käyttöoikeuskäytännöt vaativat IAM-käyttöoikeuskäytännöt-ominaisuuden vuokralaisellasi.

Tunnisteen elinikä

Luotu Frostmoln-tunniste on lyhytikäinen (noin tunti) ja injektoitu tunnusapuri uusii sen automaattisesti. Rotatoitavaa pitkäikäistä salaisuutta ei ole: käyttöoikeuden peruuttaminen tarkoittaa sidonnan poistamista (tai annotaation poistamista), minkä jälkeen kyseiselle palvelutilille ei luoda uusia tunnisteita.

Käyttöoikeuden poistaminen

• Poista sidonta (portaali, fm kubernetes workload-identity binding delete tai terraform destroy) peruuttaaksesi sen käyttöoikeuden.
• Poista annotaatio palvelutililtä lopettaaksesi tunnusten injektoinnin uusiin podeihin.

Sidonnan poistaminen on myös tapa poistaa työkuorman käyttöoikeus kokonaan — sidontaa ei voi tyhjentää siihen pisteeseen, ettei se myönnä mitään.

Terraform: poista käytännöllä myönnetty sidonta ennen sen liitosta

Koska sidontaa ei voi koskaan jättää ilman myöntöä, sen ainoan käytäntöliitoksen poistaminen hylätään. terraform destroy poistaa liitoksen ensin (se riippuu sidonnasta) ja epäonnistuu siksi. Poista sidonta ensin; se vie liitoksensa mukanaan:

terraform destroy -target=frostmoln_workload_identity_binding.my_app
terraform destroy

Sama koskee mitä tahansa muutosta, joka korvaa sidonnan — cluster_id, namespace ja service_account pakottavat kaikki korvaamisen.