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.

Työkuormaidentiteetti vaatii klusteriin Workload Identity -lisäosan (Vaihe 1). Ilman sitä mikään klusterissa ei vaihda eikä injektoi tunnuksia.

Miten se toimii

1. Lisäät klusteriin Workload Identity -lisäosan.
2. Luot sidonnan, joka yhdistää jonkin klusterisi (nimiavaruus, palvelutili) -parin vähimmän oikeuden periaatteen mukaiseen joukkoon Frostmoln-oikeuksia.
3. Merkitset kyseisen Kubernetes-palvelutilin liittymään mukaan annotaatiolla.
4. Kun pod suoritetaan kyseisellä palvelutilillä, lisäosa 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.
5. 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 — Lisää Workload Identity -lisäosa

Työkuormaidentiteetti on valinnainen klusterilisäosa, workload-identity.

• Klusteria luodessasi — valitse Workload Identity portaalin luontilomakkeessa, anna fm kubernetes cluster create -komennolle --addons workload-identity tai lisää workload-identity resurssin frostmoln_kubernetes_cluster addons-joukkoon. Klusteri ilmoitetaan ensin käynnissä olevaksi; lisäosa otetaan käyttöön muutamaa minuuttia myöhemmin.
• Käynnissä olevaan klusteriin —
  • Portaali — klusterin Lisäosat-välilehti.
  • fm CLI —

    fm kubernetes cluster add-addons <cluster-id> --addons workload-identity

  • Terraform — lisää workload-identity addons-joukkoon ja aja apply uudelleen; päivitys lisää lisäosan käynnissä olevaan klusteriin korvaamatta klusteria.

Lisäys käynnissä olevaan klusteriin ei tule voimaan heti: lisäys käynnistää oman synkronointinsa, ja lisäosa saapuu klusteriin tyypillisesti muutamassa minuutissa. Jos synkronointia ei voida käynnistää, lisäosa saapuu vasta alustan seuraavassa synkronoinnissa, enintään tunnin kuluessa.

Solmusi tarvitsevat lähtevän HTTPS-yhteyden

Lisäosan vedos haetaan osoitteesta registry.sweden.frostmoln.cloud, kun sen podi käynnistyy; sitä ei ole esiladattu solmuihisi. Tunnisteenvaihto kutsuu osoitetta api.frostmoln.cloud. Työsolmusi tarvitsevat lähtevän HTTPS-yhteyden molempiin. Alusta ei tarkista kumpaakaan; katso Luo klusteri.

Vaihe 2 — 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 3 — 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.

Jo käynnissä olevat podit

Lisäosan versiosta v0.3.0-1 alkaen palvelutilin annotointi käynnistää sen käynnissä olevat podit uudelleen, jotta ne saavat tunnuksen. Ne häädetään (eviction) yksi kerrallaan PodDisruptionBudgetit huomioiden, ja niiden controller luo ne uudelleen. Erillisiä podeja ja Job-podeja ei käynnistetä uudelleen; käynnistä ne itse. Aiemmat versiot injektoivat vain podit, jotka luodaan annotoinnin jälkeen.

Vaihe 4 — Käytä tunnusta podissasi

Suorita pod merkityllä palvelutilillä. Lisäosa 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.

Tunnus Secret-objektissa

Jotkin työkalut lukevat tunnukset Kubernetes-Secret-objektista tiedoston sijaan — External Secrets Operator on yksi niistä. Merkitse niitä varten palvelutili annotaatiolla frostmoln.cloud/workload-identity-secret: <secret-name>:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: eso
  namespace: default
  annotations:
    frostmoln.cloud/workload-identity-secret: frostmoln-token

Lisäosa ylläpitää tällöin samannimistä Opaque-tyyppistä Secret-objektia samassa nimiavaruudessa, ja siinä on vaihdettu Frostmoln-tunniste avaimen token alla. Se tarvitsee silti sidonnan kyseiselle nimiavaruudelle ja palvelutilille — ESO:lle myönnä secrets:read. Annotaatiota frostmoln.cloud/workload-identity: "true" ei tarvita; nämä kaksi tilaa ovat toisistaan riippumattomia.

• Elinikä — tunniste on voimassa noin tunnin ja uusitaan automaattisesti, kun noin 80 % sen eliniästä on kulunut.
• Merkinnät — Secretillä on merkinnät app.kubernetes.io/managed-by: frostmoln-workload-identity ja external-secrets.io/type: webhook, joten ESO:n webhook-tarjoaja voi lukea sen.
• Ei koskaan korvaa — jos samanniminen Secret on jo olemassa eikä lisäosa ole luonut sitä, mitään ei kirjoiteta. Valitse toinen nimi.
• Poistaminen — annotaation poistaminen tai nimeäminen uudelleen poistaa Secretin, ja niin tekee myös palvelutilin poistaminen.
• Ei alustan nimiavaruuksissa — kuten kube-system.

Jokainen, joka voi lukea nimiavaruuden Secret-objekteja, voi lukea tunnisteen

Pidä Secret nimiavaruudessa, jonka RBAC on tiukka. Toisin kuin API-avain, tunniste on lyhytikäinen.

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.

Lisäosan poistaminen

Poista lisäosa Lisäosat-välilehdeltä, komennolla fm kubernetes cluster remove-addons <cluster-id> --addons workload-identity tai poistamalla avain addons-joukosta Terraformissa. Sen webhook poistetaan ensin: jo käynnissä olevat podit säilyttävät injektoidun sivukonttinsa, kunnes ne käynnistetään uudelleen. Synkronoituja Secret-objekteja ei enää uusita, ja niiden tunniste vanhenee noin tunnin kuluessa.

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.