docs: update for windmill#9061

changelog/2026-05-06-azure-workload-identity-federation/index.md

@@ -0,0 +1,18 @@
+---
+slug: azure-workload-identity-federation
+title: Azure Workload Identity Federation for Key Vault backend
+tags: ['Enterprise', 'Instance settings']
+description: Authenticate the Azure Key Vault secret backend with Workload Identity Federation, removing the need to store a long-lived client secret.
+features:
+  [
+    'Workload Identity Federation as an alternative to client_secret for the Azure Key Vault backend.',
+    'Auto-detected on AKS via the workload-identity webhook (AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_FEDERATED_TOKEN_FILE).',
+    'Works on any OIDC-federated Kubernetes cluster (EKS, GKE, self-hosted).',
+    'Sovereign-cloud override via AZURE_AUTHORITY_HOST.',
+  ]
+docs: /docs/core_concepts/variables_and_secrets#azure-workload-identity-federation
+---
+
+The [Azure Key Vault secret backend](/docs/core_concepts/variables_and_secrets#azure-key-vault-backend) can now authenticate with [Azure Workload Identity Federation](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation) instead of a long-lived client secret. Leave the **Client Secret** field empty in **Instance Settings > Secret backend** and Windmill will read the projected service-account JWT from `AZURE_FEDERATED_TOKEN_FILE` and exchange it with Microsoft Entra ID for an access token - no secret is stored in the database.
+
+On AKS with the workload-identity webhook enabled, the required environment variables are injected automatically. The same flow works on any other Kubernetes cluster (EKS, GKE, self-hosted) federated to Entra ID via OIDC.

docs/core_concepts/2_variables_and_secrets/index.mdx

@@ -160,10 +160,23 @@ Once configured:
 
 ### Azure Key Vault backend
 
-Windmill can also store secrets in [Azure Key Vault](https://azure.microsoft.com/en-us/products/key-vault). Configuration requires the Key Vault URL and service principal credentials (tenant ID, client ID, client secret) with the necessary `Get`/`Set`/`Delete` permissions on the vault.
+Windmill can also store secrets in [Azure Key Vault](https://azure.microsoft.com/en-us/products/key-vault). Configuration requires the Key Vault URL and service principal credentials (tenant ID, client ID, and either a client secret or [Workload Identity Federation](#azure-workload-identity-federation)) with the necessary `Get`/`Set`/`Delete` permissions on the vault.
 
 The migration and fail-closed semantics are identical to the Vault backend.
 
+#### Azure Workload Identity Federation
+
+Instead of providing a long-lived client secret, you can leave the **Client Secret** field empty and authenticate with [Azure Workload Identity Federation](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation). When the secret is omitted, Windmill reads the projected service-account JWT from the file at `AZURE_FEDERATED_TOKEN_FILE` and exchanges it with Microsoft Entra ID for an access token, so no secret is stored.
+
+The required environment variables on the Windmill server are:
+
+- `AZURE_TENANT_ID`
+- `AZURE_CLIENT_ID`
+- `AZURE_FEDERATED_TOKEN_FILE` (path to the projected token, e.g. `/var/run/secrets/azure/tokens/azure-identity-token`)
+- `AZURE_AUTHORITY_HOST` (optional, set automatically on AKS; override for sovereign clouds)
+
+On [Azure Kubernetes Service (AKS)](https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview) with the workload-identity webhook enabled, these variables and the projected token are injected automatically once the pod's service account is annotated and labeled for workload identity. The same flow works on any other Kubernetes cluster (EKS, GKE, self-hosted) that is federated to Entra ID via OIDC.
+
 ### AWS Secrets Manager backend (Beta)
 
 Windmill can store secrets in [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/). Configuration requires: