From c55192689cd78dbb61c65eb7a0fc9a946bf77dd1 Mon Sep 17 00:00:00 2001 From: "claude[bot]" <41898282+claude[bot]@users.noreply.github.com> Date: Wed, 6 May 2026 17:16:18 +0000 Subject: [PATCH 1/2] docs: add Azure Workload Identity Federation for Key Vault backend Document the new fallback to Azure Workload Identity Federation when client_secret is omitted in the Azure Key Vault secret backend configuration. Add a dedicated changelog entry. Source: windmill-labs/windmill#9061 Co-Authored-By: Claude Opus 4.7 --- .../index.md | 18 ++++++++++++++++++ .../2_variables_and_secrets/index.mdx | 15 ++++++++++++++- 2 files changed, 32 insertions(+), 1 deletion(-) create mode 100644 changelog/2026-05-06-azure-workload-identity-federation/index.md diff --git a/changelog/2026-05-06-azure-workload-identity-federation/index.md b/changelog/2026-05-06-azure-workload-identity-federation/index.md new file mode 100644 index 000000000..8a9acc79e --- /dev/null +++ b/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. diff --git a/docs/core_concepts/2_variables_and_secrets/index.mdx b/docs/core_concepts/2_variables_and_secrets/index.mdx index ae02ceda0..0c3aab12d 100644 --- a/docs/core_concepts/2_variables_and_secrets/index.mdx +++ b/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: From d3e78f81d86a6e9977c99b28bb185f4b7e59befe Mon Sep 17 00:00:00 2001 From: hugocasa Date: Fri, 8 May 2026 17:37:47 +0200 Subject: [PATCH 2/2] docs: correct Azure WIF env vars and drop changelog entry Tenant ID and Client ID are entered in the Instance Settings UI, not read from env. Only AZURE_FEDERATED_TOKEN_FILE (and optional AZURE_AUTHORITY_HOST) are consumed from the environment by the Azure Key Vault backend. Co-Authored-By: Claude Opus 4.7 (1M context) --- .../index.md | 18 ------------------ .../2_variables_and_secrets/index.mdx | 10 ++++------ 2 files changed, 4 insertions(+), 24 deletions(-) delete mode 100644 changelog/2026-05-06-azure-workload-identity-federation/index.md diff --git a/changelog/2026-05-06-azure-workload-identity-federation/index.md b/changelog/2026-05-06-azure-workload-identity-federation/index.md deleted file mode 100644 index 8a9acc79e..000000000 --- a/changelog/2026-05-06-azure-workload-identity-federation/index.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -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. diff --git a/docs/core_concepts/2_variables_and_secrets/index.mdx b/docs/core_concepts/2_variables_and_secrets/index.mdx index 0c3aab12d..a2831e079 100644 --- a/docs/core_concepts/2_variables_and_secrets/index.mdx +++ b/docs/core_concepts/2_variables_and_secrets/index.mdx @@ -168,14 +168,12 @@ The migration and fail-closed semantics are identical to the Vault backend. 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: +The **Tenant ID** and **Client ID** of the Entra ID application are still entered in the Instance Settings form. The Windmill server additionally needs the following environment variables: -- `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) +- `AZURE_FEDERATED_TOKEN_FILE` (required): path to the projected token, e.g. `/var/run/secrets/azure/tokens/azure-identity-token`. +- `AZURE_AUTHORITY_HOST` (optional): defaults to `https://login.microsoftonline.com`; 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. +On [Azure Kubernetes Service (AKS)](https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview) with the workload-identity webhook enabled, `AZURE_FEDERATED_TOKEN_FILE` 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, as long as a projected token is mounted and `AZURE_FEDERATED_TOKEN_FILE` points to it. ### AWS Secrets Manager backend (Beta)