← spire-federation-lab docs

SPIRE → Entra ID workload identity, step by step

Picks up after the setup: SPIRE runs in the cluster, its OIDC discovery endpoint is public, and a federated identity credential on a managed identity names that SPIRE issuer. This shows what happens at runtime when a pod uses its SPIRE identity to reach Azure. Use ← → or the buttons.

AI-generated illustration, checked against the lab. IDs and hostnames are placeholders, and the repo's READMEs and code are the source of truth.

Who trusts whom (configured before any of this runs)

Entra ID → SPIREThe federated identity credential on the managed identity: SVIDs from issuer with subject and audience api://AzureADTokenExchange. Keys come from the issuer's public /keys.
Azure Storage → Entra IDAzure RBAC: the managed identity has Storage Blob Data Reader on one container.
kube-apiserver → Entra IDAuthenticationConfiguration: Entra v2 issuer, audience = the homelab-kube-apiserver app. roles map to entra:role:<role>, and RBAC binds entra:role:Cluster.Viewer → view.
Key Vault → Entra IDAzure RBAC only (no access policies): a separate managed identity, federated with …/sa/kv-reader, has Key Vault Secrets User on one secret, not the vault.
SPIRE → the podRegistration: the pod's namespace and service account decide its SPIFFE ID (ClusterSPIFFEID).