Arbetsbelastningsidentitet

Arbetsbelastningsidentitet (Workload Identity) låter en pod i ditt hanterade Kubernetes-kluster anropa Frostmoln-API:et med sitt Kubernetes-tjänstekonto — utan någon långlivad API-nyckel lagrad i podden. Det är Frostmolns motsvarighet till AWS IAM Roles for Service Accounts (IRSA), GCP Workload Identity Federation och Azure Workload Identity.

En kortlivad, avgränsad Frostmoln-uppgift skapas för podden vid behov och förnyas automatiskt. Ingenting hemligt bakas in i din avbildning eller i en Secret som du själv hanterar.

Arbetsbelastningsidentitet kräver tillägget Workload Identity i klustret (Steg 1). Utan det finns inget i klustret som byter ut eller injicerar uppgifter.

Så fungerar det

1. Du lägger till tillägget Workload Identity i klustret.
2. Du skapar en bindning som kopplar ett (namnrymd, tjänstekonto) i ett av dina kluster till en uppsättning behörigheter med minsta möjliga privilegier.
3. Du annoterar det Kubernetes-tjänstekontot för att aktivera det.
4. När en pod körs som det tjänstekontot gör tillägget automatiskt följande:
   • projicerar en kortlivad Kubernetes-tjänstekontotoken in i podden,
   • kör en liten hjälp-sidecar för uppgifter som byter den mot en avgränsad Frostmoln-token, och
   • skriver den token till en fil som appen läser.
5. Din app anropar Frostmoln-API:et med token. Den förnyas automatiskt innan den går ut (ungefär varje timme), så appen hanterar aldrig en långlivad hemlighet.

Utbytet är enkelriktat och endast utgående: plattformen når aldrig in i ditt kluster, och podden byter en token den redan har mot en Frostmoln-token den är berättigad till.

Steg 1 — Lägg till tillägget Workload Identity

Arbetsbelastningsidentitet är ett valfritt klustertillägg, workload-identity.

• När du skapar ett kluster — välj Workload Identity i portalens formulär för att skapa kluster, ange --addons workload-identity till fm kubernetes cluster create, eller ta med workload-identity i addons på frostmoln_kubernetes_cluster. Klustret rapporteras först som körs; tillägget tillämpas några minuter senare.
• I ett kluster som körs —
  • Portalen — klustrets flik Tillägg.
  • fm CLI —

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

  • Terraform — lägg till workload-identity i addons och kör apply igen; uppdateringen lägger till tillägget i det körande klustret utan att klustret ersätts.

Att lägga till det i ett kluster som körs träder inte i kraft direkt: tillägget startar en egen synkronisering och når klustret vanligtvis inom några minuter. Om den synkroniseringen inte kan startas sker det vid plattformens nästa synkronisering i stället, upp till en timme.

Dina noder behöver utgående HTTPS

Tilläggets avbildning hämtas från registry.sweden.frostmoln.cloud när dess pod startar; den är inte förinstallerad på dina noder. Tokenutbytet anropar api.frostmoln.cloud. Dina arbetsnoder behöver utgående HTTPS till båda. Plattformen kontrollerar inget av dem; se Skapa ett kluster.

Steg 2 — Skapa en bindning

En bindning ger ett specifikt tjänstekonto en specifik uppsättning behörigheter. De kommer antingen från behörigheter på själva bindningen eller från en åtkomstpolicy som kopplats till den — se Bevilja med en åtkomstpolicy nedan. Skapa bindningen i portalen, med fm-CLI:t eller med Terraform.

Portal

Öppna fliken Arbetsbelastningsidentitet på klustrets detaljsida och välj Lägg till bindning. Ange namnrymd och namnet på tjänstekontot, välj de behörigheter som ska beviljas och spara.

fm CLI

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

# Lista och ta bort
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",
  ]
}

Steg 3 — Annotera tjänstekontot

Aktivera tjänstekontot genom att lägga till annoteringen 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

Endast tjänstekonton som bär denna annotering kopplas in — det är en aktiv inställning per tjänstekonto.

Poddar som redan körs

Från tillägget v0.3.0-1 startas tjänstekontots körande poddar om när du annoterar det, så att de får uppgiften. De vräks (eviction) en i taget med hänsyn till PodDisruptionBudgets, och deras controller skapar dem på nytt. Fristående poddar och Job-poddar startas inte om; starta om dem själv. Tidigare versioner injicerar bara poddar som skapas efter annoteringen.

Steg 4 — Använd uppgiften i din pod

Kör din pod som det annoterade tjänstekontot. Tillägget injicerar allt automatiskt; din app behöver bara läsa token från filen som anges av miljövariabeln FROSTMOLN_WORKLOAD_CREDENTIALS_FILE och skicka den som en 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 förnyas på plats innan token går ut, så läs om den (i stället för att cacha dess innehåll) för långkörande processer.

Uppgift i ett Secret

Vissa verktyg läser uppgifter från ett Kubernetes-Secret i stället för från en fil — External Secrets Operator är ett av dem. För dem annoterar du tjänstekontot 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

Tillägget håller då ett Secret av typen Opaque med det namnet i samma namnrymd, med den utbytta Frostmoln-token under nyckeln token. Det behövs fortfarande en bindning för den namnrymden och det tjänstekontot — bevilja secrets:read för ESO. Annoteringen frostmoln.cloud/workload-identity: "true" behövs inte; de två lägena är oberoende av varandra.

• Livslängd — token gäller i ungefär en timme och förnyas automatiskt vid ungefär 80 % av sin livslängd.
• Etiketter — Secret bär app.kubernetes.io/managed-by: frostmoln-workload-identity och external-secrets.io/type: webhook, så att ESO:s webhook-leverantör kan läsa det.
• Skriver aldrig över — om ett Secret med det namnet redan finns och tillägget inte skapade det skrivs ingenting. Välj ett annat namn.
• Borttagning — att ta bort eller byta namn på annoteringen raderar Secret, och det gör även att radera tjänstekontot.
• Inte i plattformens namnrymder — till exempel kube-system.

Alla som kan läsa Secrets i namnrymden kan läsa token

Håll Secret i en namnrymd med snäv RBAC. Till skillnad från en API-nyckel är token kortlivad.

Behörigheter

Arbetsbelastningsidentiteter har minsta möjliga privilegier som princip. En bindnings behörigheter måste vara explicita och konkreta — jokertecknen * (alla) och <resurs>:* (t.ex. compute:*) avvisas. Bevilja endast de behörigheter som arbetsbelastningen faktiskt behöver, till exempel:

• compute:read — läs instanser, avbildningar, flavors
• storage:read — läs volymer och buckets
• network:read — läs VPC:er, subnät, säkerhetsgrupper

För att bredda eller begränsa åtkomsten senare uppdaterar du bindningens behörigheter — ändringen träder i kraft vid nästa tokenförnyelse.

Bevilja med en åtkomstpolicy

Behörigheter är grovkorniga: compute:read ger läsning av alla instanser, avbildningar och flavors. En åtkomstpolicy kan peka ut enskilda resurser, lägga till villkor som ett käll-IP-intervall och neka explicit. För en arbetsbelastning som bara ska nå en bucket från ett nätverk uttrycker en policy det som en behörighet inte kan.

Skapa bindningen utan behörigheter och koppla en policy till den.

# Skapa en bindning utan behörigheter
fm kubernetes workload-identity binding create \
  --cluster <cluster-id> --namespace ops --service-account reaper

# Koppla en policy till den
fm iam policy attach <policy-id> --type workload_identity --id <binding-id>

I portalen lämnar du behörighetsväljaren tom när du lägger till bindningen och kopplar sedan en policy under Inställningar → Åtkomstpolicyer. I Terraform utelämnar du scopes och lägger till en frostmoln_iam_policy_attachment.

En bindning utan behörigheter listas som inga behörigheter — varken portalen eller fm kan skilja en som beviljas av en kopplad policy från en som inte beviljar något, så ingen av dem påstår det. Tre saker är värda att känna till:

• Den är verkningslös tills en policy kopplats. Utan något som beviljar den vägrar tokenutbytet att skapa en token i stället för att utfärda en som inte ger något — poddens uppgiftshjälpare rapporterar ett fel i stället för att få en död token.
• En bindning kan aldrig lämnas utan någon behörighet alls. Att ta bort dess sista kvarvarande beviljande — behörigheterna eller den sista policyn — avvisas. Ta bort bindningen i stället.
• Så länge en bindning har både behörigheter och en policy är det behörigheterna som gäller. Policyns ytterligare rättigheter träder i kraft först när behörigheterna tagits bort, så verifiera efter borttagningen — inte efter kopplingen.

Åtkomstpolicyer kräver funktionen IAM-åtkomstpolicyer på din tenant.

Tokens livslängd

Den skapade Frostmoln-token är kortlivad (ungefär en timme) och förnyas automatiskt av den injicerade uppgiftshjälparen. Det finns ingen långlivad hemlighet att rotera: att återkalla åtkomst innebär att ta bort bindningen (eller ta bort annoteringen), varefter inga nya token skapas för det tjänstekontot.

Ta bort åtkomst

• Ta bort bindningen (portalen, fm kubernetes workload-identity binding delete eller terraform destroy) för att återkalla dess åtkomst.
• Ta bort annoteringen från tjänstekontot för att sluta injicera uppgifter i nya poddar.

Ta bort tillägget

Ta bort tillägget från fliken Tillägg, med fm kubernetes cluster remove-addons <cluster-id> --addons workload-identity, eller genom att ta bort nyckeln ur addons i Terraform. Dess webhook tas bort först: poddar som redan körs behåller sin injicerade sidecar tills de startas om. Synkade Secrets förnyas inte längre, och deras token går ut inom ungefär en timme.

Att ta bort bindningen är också hur du tar bort en arbetsbelastnings åtkomst helt — en bindning kan inte tömmas ner till att inte bevilja något.

Terraform: ta bort en policybeviljad bindning före dess koppling

Eftersom en bindning aldrig kan lämnas utan beviljande avvisas borttagning av dess enda policykoppling. terraform destroy tar bort kopplingen först (den beror på bindningen) och misslyckas därför. Ta bort bindningen först; det tar med sig dess kopplingar:

terraform destroy -target=frostmoln_workload_identity_binding.my_app
terraform destroy

Detsamma gäller varje ändring som ersätter bindningen — cluster_id, namespace och service_account tvingar alla fram en ersättning.