Arbejdslastidentitet

Arbejdslastidentitet (Workload Identity) lader en pod i din administrerede Kubernetes-klynge kalde Frostmoln-API'et med sin Kubernetes-ServiceAccount — uden nogen langlivet API-nøgle gemt i podden. Det er Frostmolns modstykke til AWS IAM Roles for Service Accounts (IRSA), GCP Workload Identity Federation og Azure Workload Identity.

En kortlivet, afgrænset Frostmoln-legitimationsoplysning udstedes til podden efter behov og fornyes automatisk. Intet hemmeligt bages ind i dit image eller i en Secret, som du selv administrerer.

Arbejdslastidentitet kræver tilføjelsen Workload Identity på klyngen (Trin 1). Uden den er der intet i klyngen, der udveksler eller injicerer legitimationsoplysninger.

Sådan fungerer det

1. Du føjer tilføjelsen Workload Identity til klyngen.
2. Du opretter en binding, der knytter en (namespace, serviceAccount) i en af dine klynger til et sæt Frostmoln-adgange med mindst mulige privilegier.
3. Du annoterer den Kubernetes-ServiceAccount for at tilmelde den.
4. Når en pod kører som den ServiceAccount, gør tilføjelsen automatisk følgende:
   • projicerer et kortlivet Kubernetes-ServiceAccount-token ind i podden,
   • kører en lille hjælpe-sidecar til legitimationsoplysninger, som bytter det til et afgrænset Frostmoln-token, og
   • skriver det token til en fil, som appen læser.
5. Din app kalder Frostmoln-API'et med tokenet. Det fornyes automatisk, inden det udløber (omtrent hver time), så appen håndterer aldrig en langlivet hemmelighed.

Udvekslingen er envejs og kun udgående: platformen når aldrig ind i din klynge, og podden bytter et token, den allerede har, til et Frostmoln-token, den er berettiget til.

Trin 1 — Føj tilføjelsen Workload Identity til klyngen

Arbejdslastidentitet er en valgfri klyngetilføjelse, workload-identity.

• Når du opretter en klynge — vælg Workload Identity i portalens oprettelsesformular, angiv --addons workload-identity til fm kubernetes cluster create, eller medtag workload-identity i addons på frostmoln_kubernetes_cluster. Klyngen rapporteres først som kører; tilføjelsen anvendes nogle minutter senere.
• Til en klynge, der kører —
  • Portalen — klyngens fane Tilføjelser.
  • fm CLI —

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

  • Terraform — føj workload-identity til addons, og kør apply igen; opdateringen føjer tilføjelsen til den kørende klynge uden at erstatte den.

At føje den til en klynge, der kører, træder ikke i kraft med det samme: tilføjelsen starter sin egen synkronisering og når klyngen typisk inden for få minutter. Kan den synkronisering ikke startes, sker det først ved platformens næste synkronisering, op til en time.

Dine noder har brug for udgående HTTPS

Tilføjelsens image hentes fra registry.sweden.frostmoln.cloud, når dens pod starter; det er ikke forudindlæst på dine noder. Tokenudvekslingen kalder api.frostmoln.cloud. Dine arbejdernoder har brug for udgående HTTPS til begge. Platformen kontrollerer ingen af delene; se Opret en klynge.

Trin 2 — Opret en binding

En binding giver en bestemt ServiceAccount et bestemt sæt tilladelser. De kommer enten fra adgange på selve bindingen eller fra en adgangspolitik, der er knyttet til den — se Tildel med en adgangspolitik nedenfor. Opret bindingen i portalen, med fm-CLI'en eller med Terraform.

Portal

Åbn fanen Arbejdslastidentitet på klyngens detaljeside, og vælg Tilføj binding. Angiv navnet på namespace og serviceaccount, vælg de adgange, der skal tildeles, og gem.

fm CLI

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

# Vis og slet
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",
  ]
}

Trin 3 — Annotér din ServiceAccount

Tilmeld din ServiceAccount ved at tilføje annotationen 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

Kun ServiceAccounts, der bærer denne annotation, kobles op — det er en tilvalgt indstilling pr. ServiceAccount.

Pods, der allerede kører

Fra tilføjelsen v0.3.0-1 genstartes ServiceAccountens kørende pods, når du annoterer den, så de får legitimationsoplysningen. De evictes én ad gangen med respekt for PodDisruptionBudgets, og deres controller genopretter dem. Enkeltstående pods og Job-pods genstartes ikke; genstart dem selv. Tidligere versioner injicerer kun pods, der oprettes efter annotationen.

Trin 4 — Brug legitimationsoplysningen i din pod

Kør din pod som den annoterede ServiceAccount. Tilføjelsen injicerer alt automatisk; din app skal blot læse tokenet fra den fil, som miljøvariablen FROSTMOLN_WORKLOAD_CREDENTIALS_FILE angiver, 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, inden tokenet udløber, så læs den igen (i stedet for at cache dens indhold) i langvarige processer.

Legitimationsoplysning i en Secret

Nogle værktøjer læser legitimationsoplysninger fra en Kubernetes-Secret i stedet for fra en fil — External Secrets Operator er et af dem. Til dem annoterer du ServiceAccount'en 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

Tilføjelsen holder derefter en Opaque-Secret med det navn i samme navnerum, som indeholder det udvekslede Frostmoln-token under nøglen token. Den kræver stadig en binding for det navnerum og den ServiceAccount — tildel secrets:read til ESO. Annotationen frostmoln.cloud/workload-identity: "true" er ikke nødvendig; de to tilstande er uafhængige af hinanden.

• Levetid — tokenet gælder i omkring en time og fornyes automatisk ved omkring 80 % af dets levetid.
• Etiketter — Secret'en bærer app.kubernetes.io/managed-by: frostmoln-workload-identity og external-secrets.io/type: webhook, så ESO's webhook-udbyder kan læse den.
• Overskriver aldrig — findes der allerede en Secret med det navn, som tilføjelsen ikke har oprettet, skrives der intet. Vælg et andet navn.
• Fjernelse — at fjerne eller omdøbe annotationen sletter Secret'en, og det gør det også at slette ServiceAccount'en.
• Ikke i platformens navnerum — såsom kube-system.

Alle, der kan læse Secrets i navnerummet, kan læse tokenet

Hold Secret'en i et navnerum med stram RBAC. I modsætning til en API-nøgle er tokenet kortlivet.

Adgange

Arbejdslastidentiteter har mindst mulige privilegier som designprincip. En bindings adgange skal være eksplicitte og konkrete — jokertegnene * (alle) og <ressource>:* (f.eks. compute:*) afvises. Tildel kun de adgange, som arbejdslasten faktisk har brug for, for eksempel:

• compute:read — læs instanser, images, flavors
• storage:read — læs volumener og buckets
• network:read — læs VPC'er, subnets, sikkerhedsgrupper

For at udvide eller indsnævre adgangen senere opdaterer du bindingens adgange — ændringen træder i kraft ved næste tokenfornyelse.

Tildel med en adgangspolitik

Adgange er grovkornede: compute:read giver læsning på tværs af alle instanser, images og flavors. En adgangspolitik kan udpege enkelte ressourcer, tilføje betingelser som et kilde-IP-interval og nægte eksplicit. For en arbejdslast, der kun skal røre én bucket fra ét netværk, udtrykker en politik det, en adgang ikke kan.

For at bruge en sådan opretter du bindingen uden adgange og knytter en politik til den.

# Opret en binding uden adgange
fm kubernetes workload-identity binding create \
  --cluster <cluster-id> --namespace ops --service-account reaper

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

I portalen lader du adgangsvælgeren stå tom, når du tilføjer bindingen, og knytter derefter en politik under Indstillinger → Adgangspolitikker. I Terraform udelader du scopes og tilføjer en frostmoln_iam_policy_attachment.

En binding uden adgange vises som ingen adgange — hverken portalen eller fm kan skelne en, der tildeles af en tilknyttet politik, fra en, der intet tildeler, så ingen af dem påstår det. Tre ting er værd at kende:

• Den er uvirksom, indtil en politik er knyttet til den. Uden noget, der tildeler den noget, nægter tokenudvekslingen at udstede i stedet for at udstede en legitimationsoplysning, der intet giver — poddens hjælper til legitimationsoplysninger rapporterer en fejl i stedet for at få et dødt token.
• En binding kan aldrig efterlades uden at tildele noget. At fjerne dens sidste tilbageværende tildeling — dens adgange eller dens sidste politik — afvises. Slet bindingen i stedet.
• Så længe en binding har både adgange og en politik, er det adgangene, der gælder. Politikkens yderligere tilladelser træder først i kraft, når adgangene er fjernet, så verificer efter at du har fjernet dem — ikke efter at du har knyttet politikken.

Adgangspolitikker kræver funktionen IAM-adgangspolitikker på din tenant.

Tokenets levetid

Det udstedte Frostmoln-token er kortlivet (omkring en time) og fornyes automatisk af den injicerede hjælper til legitimationsoplysninger. Der er ingen langlivet hemmelighed at rotere: at tilbagekalde adgang er et spørgsmål om at slette bindingen (eller fjerne annotationen), hvorefter der ikke udstedes nye tokens til den ServiceAccount.

Fjernelse af adgang

• Slet bindingen (portalen, fm kubernetes workload-identity binding delete eller terraform destroy) for at tilbagekalde dens adgang.
• Fjern annotationen fra din ServiceAccount for at stoppe injiceringen af legitimationsoplysninger i nye pods.

Fjernelse af tilføjelsen

Fjern tilføjelsen fra fanen Tilføjelser, med fm kubernetes cluster remove-addons <cluster-id> --addons workload-identity eller ved at fjerne nøglen fra addons i Terraform. Dens webhook fjernes først: pods, der allerede kører, beholder deres injicerede sidecar, indtil de genstartes. Synkroniserede Secrets fornyes ikke længere, og deres token udløber inden for omkring en time.

At slette bindingen er også måden, hvorpå du fjerner en arbejdslasts adgang helt — en binding kan ikke tømmes ned til ikke at tildele noget.

Terraform: slet en politiktildelt binding før dens tilknytning

Fordi en binding aldrig kan efterlades uden nogen tildeling, afvises det at frakoble dens eneste politik. terraform destroy fjerner tilknytningen først (den afhænger af bindingen) og mislykkes derfor. Slet bindingen først; det fjerner dens tilknytninger med den:

terraform destroy -target=frostmoln_workload_identity_binding.my_app
terraform destroy

Det samme gælder enhver ændring, der erstatter bindingen — cluster_id, namespace og service_account fremtvinger alle en erstatning.