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.

Pilot — åtkomst beviljas per tenant

Arbetsbelastningsidentitet lanseras som en pilot. Den är endast tillgänglig för tenanter som har behörigheten workload-identity, och endast på hanterade Kubernetes-kluster i en sådan tenant. Om du inte ser fliken Arbetsbelastningsidentitet på ett kluster är den inte aktiverad för din tenant ännu — kontakta supporten för att begära åtkomst.

Så fungerar det

1. 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.
2. Du annoterar det Kubernetes-tjänstekontot för att aktivera det.
3. När en pod körs som det tjänstekontot gör klustret 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.
4. 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 — 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 2 — 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.

Steg 3 — Använd uppgiften i din pod

Kör din pod som det annoterade tjänstekontot. Plattformen 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.

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.

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.