Skip to main content

Integrating with Azure Key Vault

Flyte integrates with Azure Key Vault to provide secure secret management for both task execution and internal services. This integration is implemented through two primary components: the AzureSecretManagerInjector, which uses a Kubernetes pod webhook to inject secrets into task pods, and the AzureSecretFetcher, which provides direct SDK-based access to secrets.

Enabling Azure Key Vault Integration

To enable Azure Key Vault as a secret manager, you must configure the webhook section in the Flyte configuration. This tells the Flyte pod webhook to use the Azure-specific injector when a task requests a secret.

webhook:
secretManagerTypes:
- Azure
azureSecretManager:
sidecarImage: "mcr.microsoft.com/azure-cli:cbl-mariner2.0"
resources:
requests:
cpu: "200m"
memory: "500Mi"
limits:
cpu: "200m"
memory: "500Mi"

The sidecarImage is used for the init-container that pulls secrets from Azure Key Vault.

Injecting Secrets into Task Pods

The AzureSecretManagerInjector (found in flyteplugins/go/tasks/pluginmachinery/secret/azure_secret_manager.go) handles the mutation of task pods. When a task requests a secret, the injector adds an init-container to the pod that uses the Azure CLI to download the secret into a shared memory volume.

Requirements for Injection

  1. Secret Group as URI: The Group field of the core.Secret must be the full Azure Key Vault Secret URI.
  2. Workload Identity: The task pod must be configured for Azure Workload Identity Federation. The injector expects the environment variables AZURE_CLIENT_ID, AZURE_TENANT_ID, and AZURE_FEDERATED_TOKEN_FILE to be present.
  3. Mount Requirement: Only Secret_FILE or Secret_ANY mount requirements are supported. Secret_ENV_VAR is not supported for Azure Key Vault.

Example Secret Definition

In your task definition, specify the secret using the full URI:

secret := &core.Secret{
Group: "https://my-vault.vault.azure.net/secrets/my-secret-name",
GroupVersion: "optional-version-id",
MountRequirement: core.Secret_FILE,
}

The injector will mount the secret at /etc/flyte/secrets/<secret-name>/<version> (or just <secret-name> if no version is provided).

Direct Secret Retrieval

For internal Flyte services or when using the EmbeddedSecretManager, Flyte uses the AzureSecretFetcher (flyteplugins/go/tasks/pluginmachinery/secret/azure_secret_fetcher.go). This fetcher uses the Azure SDK for Go to retrieve secrets directly.

To configure the embedded fetcher:

webhook:
embeddedSecretManagerConfig:
type: Azure
azureConfig:
vaultURI: "https://my-vault.vault.azure.net/"

Secret Name Encoding

Flyte uses a specific encoding scheme to map its internal secret IDs (which often contain underscores and other characters) to Azure-compatible secret names. This is handled by EncodeAzureSecretName in flyteplugins/go/tasks/pluginmachinery/secret/azure_utils.go.

The encoding follows these rules:

  • Uses 0 as an escape character.
  • Uses 1 to escape hyphens.
  • Encodes the secret name component using base32.
  • Combines components (Org, Domain, Project, Name) using a hyphen -.

Warning: Azure secret names have a 127-character limit. If the encoded name exceeds this length, the secret retrieval will fail.

Secret Value Formatting

When using the AzureSecretFetcher (or the EmbeddedSecretManager), Flyte expects secrets in Azure Key Vault to be stored as JSON-wrapped strings. This allows Flyte to distinguish between plain strings and binary data (which Azure Key Vault does not support natively).

The AzureToUnionSecret function decodes these values:

String Secret Format

{
"type": 0,
"value": "your-secret-string"
}

Binary Secret Format

{
"type": 1,
"value": "base64-encoded-binary-data"
}

Troubleshooting and Gotchas

  • Environment Variables: The AzureSecretManagerInjector does not support injecting secrets directly as environment variables. You must mount them as files and read them from the filesystem.
  • URI Validation: Ensure the Group field in your secret request is a valid Azure Key Vault URI. The injector parses this URI to extract the secret name.
  • Init-Container Logs: If a secret fails to mount, check the logs of the azure-pull-secret-<index> init-container in the task pod. It runs the az keyvault secret show command and will report authentication or permission errors.
  • Permissions: The managed identity associated with the pod must have the Key Vault Secrets User role (or equivalent get permissions) on the specific Key Vault or secret.