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.

Arbeidslastidentitet krever tillegget Workload Identity på klyngen (Trinn 1). Uten det er det ingenting i klyngen som bytter ut eller injiserer legitimasjon.

Slik fungerer det

1. Du legger til tillegget Workload Identity i klyngen.
2. Du oppretter en binding som knytter et (navnerom, tjenestekonto) i en av klyngene dine til et sett med rettigheter med minst mulig privilegium.
3. Du annoterer det Kubernetes-tjenestekontoen for å melde det på.
4. Når en pod kjører som det tjenestekontoen, gjør tillegget 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.
5. 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 — Legg til tillegget Workload Identity

Arbeidslastidentitet er et valgfritt klyngetillegg, workload-identity.

• Når du oppretter en klynge — velg Workload Identity i portalens opprettingsskjema, gi --addons workload-identity til fm kubernetes cluster create, eller ta med workload-identity i addons på frostmoln_kubernetes_cluster. Klyngen rapporteres først som kjører; tillegget tas i bruk noen minutter senere.
• I en klynge som kjører —
  • Portalen — klyngens fane Tillegg.
  • fm CLI —

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

  • Terraform — legg workload-identity til i addons og kjør apply på nytt; oppdateringen legger tillegget til i klyngen som kjører, uten å erstatte den.

Å legge det til i en klynge som kjører, trer ikke i kraft umiddelbart: tillegget starter sin egen synkronisering og når klyngen vanligvis i løpet av noen minutter. Kan ikke den synkroniseringen startes, skjer det først ved plattformens neste synkronisering, inntil en time.

Nodene dine trenger utgående HTTPS

Tilleggets bilde hentes fra registry.sweden.frostmoln.cloud når poden starter; det er ikke forhåndslastet på nodene dine. Tokenutvekslingen kaller api.frostmoln.cloud. Arbeidsnodene dine trenger utgående HTTPS til begge. Plattformen sjekker ingen av delene; se Opprette en klynge.

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

Poder som allerede kjører

Fra tillegget v0.3.0-1 startes tjenestekontoens kjørende poder på nytt når du annoterer den, slik at de får legitimasjonen. De evictes én om gangen med respekt for PodDisruptionBudgets, og controlleren deres oppretter dem på nytt. Frittstående poder og Job-poder startes ikke på nytt; start dem på nytt selv. Tidligere versjoner injiserer bare poder som opprettes etter annotasjonen.

Trinn 4 — Bruk legitimasjonen i poden din

Kjør poden din som det annoterte tjenestekontoen. Tillegget 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.

Legitimasjon i et Secret

Noen verktøy leser legitimasjon fra et Kubernetes-Secret i stedet for fra en fil — External Secrets Operator er ett av dem. For slike verktøy annoterer du tjenestekontoen med frostmoln.cloud/workload-identity-secret: <secret-name>:

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

Tillegget holder da et Opaque-Secret med det navnet i samme navnerom, med det utvekslede Frostmoln-tokenet under nøkkelen token. Det trenger fortsatt en binding for det navnerommet og den tjenestekontoen — gi secrets:read for ESO. Annotasjonen frostmoln.cloud/workload-identity: "true" trengs ikke; de to modusene er uavhengige av hverandre.

• Levetid — tokenet varer omtrent én time og fornyes automatisk ved omtrent 80 % av levetiden.
• Etiketter — Secret-et har app.kubernetes.io/managed-by: frostmoln-workload-identity og external-secrets.io/type: webhook, slik at ESOs webhook-leverandør kan lese det.
• Overskriver aldri — finnes det allerede et Secret med det navnet som tillegget ikke har opprettet, skrives ingenting. Velg et annet navn.
• Fjerning — å fjerne eller endre navnet i annotasjonen sletter Secret-et, og det gjør også sletting av tjenestekontoen.
• Ikke i plattformens navnerom — som kube-system.

Alle som kan lese Secrets i navnerommet, kan lese tokenet

Hold Secret-et i et navnerom med stram RBAC. I motsetning til en API-nøkkel er tokenet kortlivd.

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.

Fjerne tillegget

Fjern tillegget fra fanen Tillegg, med fm kubernetes cluster remove-addons <cluster-id> --addons workload-identity, eller ved å fjerne nøkkelen fra addons i Terraform. Webhooken fjernes først: poder som allerede kjører, beholder den injiserte sidecaren til de startes på nytt. Synkroniserte Secrets fornyes ikke lenger, og tokenet deres utløper innen omtrent en time.

Å 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.