Docs: document all secret backend configuration options (with required markers) — example: Azure Key Vault

[xdatanomad]

Summary

The Secret Backends section of the configuration docs is missing a full reference of the properties each backend accepts. Today users have to read the plugin source to discover which fields exist, which are required, and which credential modes are supported (client-secret, managed identity, workload identity, etc.).

Requested change

For every secret backend (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, Kubernetes, Elasticsearch, JDBC, etc.), add a reference table under kestra.secret.<backend> that lists:

• Property name
• Type
• Whether it is required or optional
• Default value (if any)
• Short description
• Which auth mode the property belongs to (e.g. static credentials vs. managed identity vs. workload identity)

Also document:

• The minimum config needed to boot the backend.
• The credential-resolution order (which property short-circuits which fallback).
• Read-only mode and any filter properties (filterOnPrefix, filterOnTags, excludedTags, etc.).

Example — Azure Key Vault

Config prefix: kestra.secret.azure-key-vault

Property	Type	Required	Description
keyVaultUri	string	required if vaultName unset	Full vault URI (e.g. https://<vault>.vault.azure.net).
vaultName	string	required if keyVaultUri unset	Vault short name — URI is derived from it.
prefix	string	optional (default kestra)	Prefix applied to secret names.
tags	map	optional	Tags applied on write.
clientSecret.tenantId	string	optional	Service-principal tenant ID.
clientSecret.clientId	string	optional	Service-principal client ID.
clientSecret.clientSecret	string	optional	Service-principal secret.
managedIdentityClientId	string	optional	User/system-assigned MI client ID (falls back to AZURE_CLIENT_ID).
managedIdentityResourceId	string	optional	MI resource ID.
workloadIdentityClientId	string	optional	Entra app client ID for AKS workload identity.
additionallyAllowedTenants	list	optional	Extra tenants for multi-tenant apps ("*" for any).
filterOnPrefix	object	optional (read-only)	{ prefix, keepPrefix } filter.
filterOnTags	map	optional (read-only)	Include filter.
excludedTags	map	optional (read-only)	Exclude filter.
readOnly	boolean	optional	Put backend in read-only mode.

Minimum config:

kestra:
  secret:
    azure-key-vault:
      vaultName: my-vault

Credential resolution order:

1. If clientSecret.* is set → service-principal auth.
2. Otherwise → DefaultAzureCredential chain (env vars, managed identity, workload identity, Azure CLI…), honoring managedIdentityClientId / managedIdentityResourceId / workloadIdentityClientId / additionallyAllowedTenants when set.

Managed identity example (AKS workload identity):

kestra:
  secret:
    azure-key-vault:
      keyVaultUri: https://my-vault.vault.azure.net
      workloadIdentityClientId: <entra-app-client-id>

Why this matters

Enterprise users evaluating Kestra for production repeatedly ask "does this support managed identity?" and "what's the minimum config?" — both are answerable from source but not from the docs today.