Arbeidslastidentitet

Arbeidslastidentitet (Workload Identity) lar en pod i det administrerte Kubernetes-klyngen din kalle Frostmoln-API-et med sitt Kubernetes-tjenestekonto — uten noen langlivd API-nøkkel lagret i poden. Det er Frostmolns motstykke til AWS IAM Roles for Service Accounts (IRSA), GCP Workload Identity Federation og Azure Workload Identity.

En kortlivd, avgrenset Frostmoln-legitimasjon opprettes for poden ved behov og fornyes automatisk. Ingenting hemmelig bakes inn i imaget ditt eller i en Secret du selv administrerer.

Pilot — tilgang gis per tenant

Arbeidslastidentitet rulles ut som en pilot. Den er kun tilgjengelig for tenanter som har rettigheten workload-identity, og kun på administrerte Kubernetes-klynger i en slik tenant. Hvis du ikke ser fanen Arbeidslastidentitet på en klynge, er den ikke aktivert for din tenant ennå — kontakt support for å be om tilgang.

Slik fungerer det

1. Du oppretter en binding som knytter et (navnerom, tjenestekonto) i en av klyngene dine til et sett med rettigheter med minst mulig privilegium.
2. Du annoterer det Kubernetes-tjenestekontoen for å melde det på.
3. Når en pod kjører som det tjenestekontoen, gjør klyngen automatisk følgende:
   • projiserer et kortlivd Kubernetes-tjenestekontotoken inn i poden,
   • kjører en liten legitimasjonshjelper-sidecar som bytter det mot et avgrenset Frostmoln-token, og
   • skriver dette token til en fil som appen leser.
4. Appen din kaller Frostmoln-API-et med token. Det fornyes automatisk før det utløper (omtrent hver time), så appen håndterer aldri en langlivd hemmelighet.

Utvekslingen er enveis og kun utgående: plattformen når aldri inn i klyngen din, og poden bytter et token den allerede har mot et Frostmoln-token den er berettiget til.

Trinn 1 — Opprett en binding

En binding gir et bestemt tjenestekonto et bestemt sett med rettigheter. De kommer enten fra rettigheter på selve bindingen eller fra en tilgangspolicy som er knyttet til den — se Gi tilgang med en tilgangspolicy nedenfor. Opprett bindingen i portalen, med fm-CLI-et eller med Terraform.

Portal

Åpne fanen Arbeidslastidentitet på klyngens detaljside og velg Legg til binding. Skriv inn navnerom og navnet på tjenestekontoen, velg rettighetene som skal gis, og lagre.

fm CLI

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

# List og slett
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",
  ]
}

Trinn 2 — Annoter tjenestekontoen

Meld tjenestekontoen på ved å legge til annotasjonen frostmoln.cloud/workload-identity: "true":

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

eller imperativt:

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

Bare tjenestekontoer som har denne annotasjonen kobles opp — det er en påmelding per tjenestekonto.

Trinn 3 — Bruk legitimasjonen i poden din

Kjør poden din som det annoterte tjenestekontoen. Plattformen injiserer alt automatisk; appen din trenger bare å lese token fra filen som er navngitt av miljøvariabelen FROSTMOLN_WORKLOAD_CREDENTIALS_FILE, og sende det som et bearer-token:

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)))

Filen fornyes på stedet før token utløper, så les den på nytt (i stedet for å bufre innholdet) for langvarige prosesser.

Rettigheter

Arbeidslastidentiteter har minst mulig privilegium som prinsipp. En bindings rettigheter må være eksplisitte og konkrete — jokertegnene * (alle) og <ressurs>:* (f.eks. compute:*) avvises. Gi bare de rettighetene arbeidslasten faktisk trenger, for eksempel:

• compute:read — les instanser, images, flavors
• storage:read — les volumer og buckets
• network:read — les VPC-er, subnett, sikkerhetsgrupper

For å utvide eller innsnevre tilgangen senere oppdaterer du bindingens rettigheter — endringen trer i kraft ved neste tokenfornyelse.

Gi tilgang med en tilgangspolicy

Rettigheter er grovkornede: compute:read gir lesing av alle instanser, images og flavors. En tilgangspolicy kan peke ut enkeltressurser, legge til betingelser som et kilde-IP-område, og nekte eksplisitt. For en arbeidslast som bare skal nå én bucket fra ett nettverk uttrykker en policy det en rettighet ikke kan.

Opprett bindingen uten rettigheter og knytt en policy til den.

# Opprett en binding uten rettigheter
fm kubernetes workload-identity binding create \
  --cluster <cluster-id> --namespace ops --service-account reaper

# Knytt en policy til den
fm iam policy attach <policy-id> --type workload_identity --id <binding-id>

I portalen lar du rettighetsvelgeren stå tom når du legger til bindingen, og knytter deretter en policy under Innstillinger → Tilgangspolicyer. I Terraform utelater du scopes og legger til en frostmoln_iam_policy_attachment.

En binding uten rettigheter listes som ingen rettighet — verken portalen eller fm kan skille en som gis av en tilknyttet policy fra en som ikke gir noe, så ingen av dem påstår det. Tre ting er verdt å vite:

• Den er virkningsløs til en policy er knyttet til den. Uten noe som gir den tilgang nekter tokenutvekslingen å opprette et token i stedet for å utstede ett som ikke gir noe — podens legitimasjonshjelper melder en feil i stedet for å få et dødt token.
• En binding kan aldri stå igjen uten noen tilgang i det hele tatt. Å fjerne den siste gjenværende tildelingen — rettighetene eller den siste policyen — avvises. Slett bindingen i stedet.
• Så lenge en binding har både rettigheter og en policy, er det rettighetene som gjelder. Policyens ekstra tilganger trer først i kraft når rettighetene er fjernet, så verifiser etter fjerningen — ikke etter tilknytningen.

Tilgangspolicyer krever funksjonen IAM-tilgangspolicyer på tenanten din.

Tokenets levetid

Det opprettede Frostmoln-tokenet er kortlivd (omtrent én time) og fornyes automatisk av den injiserte legitimasjonshjelperen. Det finnes ingen langlivd hemmelighet å rotere: å tilbakekalle tilgang er å slette bindingen (eller fjerne annotasjonen), hvoretter ingen nye token opprettes for det tjenestekontoen.

Fjerne tilgang

• Slett bindingen (portalen, fm kubernetes workload-identity binding delete eller terraform destroy) for å tilbakekalle tilgangen.
• Fjern annotasjonen fra tjenestekontoen for å slutte å injisere legitimasjon i nye poder.

Å slette bindingen er også måten du fjerner en arbeidslasts tilgang helt på — en binding kan ikke tømmes ned til å gi ingenting.

Terraform: slett en policygitt binding før tilknytningen

Fordi en binding aldri kan stå igjen uten tildeling, avvises fjerning av dens eneste policytilknytning. terraform destroy fjerner tilknytningen først (den avhenger av bindingen) og feiler derfor. Slett bindingen først; det tar med seg tilknytningene:

terraform destroy -target=frostmoln_workload_identity_binding.my_app
terraform destroy

Det samme gjelder enhver endring som erstatter bindingen — cluster_id, namespace og service_account tvinger alle fram en erstatning.