Use Azure Key Vault

Deployment model: On-premises
Configuration reference: The external-secrets.io/v1 API.
Validation scope: Manifest/schema checks; Azure identity execution requires validation in your environment.

Use this page to create the qodo-secrets store consumed by the shared Qodo Secret examples. Qodo application Pods do not need Azure permissions for this integration. For more information, see Manage Qodo secrets with External Secrets Operator.

Before you begin

Complete the common ESO controller, webhook, CRD, namespace, and permission checks first. For more information, see Before you begin. Prepare an AKS cluster configured for OIDC federation and Microsoft Entra Workload ID, an approved Azure identity, its client and tenant IDs, your Key Vault URL, and network access from ESO to the vault and token endpoints. ESO must be able to request a token for the referenced Kubernetes service account. For more information, see Use Microsoft Entra Workload ID with AKS. Before creating the store, ensure the referenced identity has a matching federated credential and Key Vault data-plane Secret read permission, and the source Secret version is enabled. Verify vault firewall/private endpoint access from ESO. The required subject, audience, and role are listed below. This example uses a referenced service account so the store selects the identity. It does not require annotating Qodo application Pods or supplying a long-lived Azure client secret.

1. Prepare the vault Secret and permissions

Using your approved secret-management process, create Key Vault Secret qodo-database. Its value must be JSON containing POSTGRES_PASSWORD with the existing database password. Keep actual values out of Git, Helm values, shell arguments, and chat. Configure the identity through your Azure administration process:

Setting	Required value
Federated credential issuer	Your cluster’s OIDC issuer
Federated credential subject	`system:serviceaccount:qodo:qodo-secrets-reader`
Federated credential audience	`api://AzureADTokenExchange`
Secret read access	`Key Vault Secrets User` scoped to the intended vault or approved narrower scope when using Azure RBAC

For a vault using legacy access policies, grant the required Secret Get permission instead. These examples read secrets; they do not require permission to write or delete vault contents. For more information, see Azure Key Vault authentication.

2. Configure the service account and store

Replace the client ID, tenant ID, and vault name before applying. These are identity and resource identifiers, not credential values.

azure-secret-store.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: qodo-secrets-reader
  namespace: qodo
  annotations:
    azure.workload.identity/client-id: REPLACE_WITH_AZURE_CLIENT_ID
    azure.workload.identity/tenant-id: REPLACE_WITH_AZURE_TENANT_ID
---
apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: qodo-secrets
  namespace: qodo
spec:
  provider:
    azurekv:
      authType: WorkloadIdentity
      vaultUrl: https://REPLACE-WITH-VAULT-NAME.vault.azure.net
      serviceAccountRef:
        name: qodo-secrets-reader

The example uses a namespaced store. When reusing an approved ClusterSecretStore, retain its name and scope and ensure its service account reference identifies the correct namespace. For more information, see Referenced service account.

3. Reconcile and verify

Select the target context explicitly. These examples use namespace qodo:

KUBE_CONTEXT="REPLACE_WITH_YOUR_CONTEXT"
NAMESPACE=qodo

kubectl --context "$KUBE_CONTEXT" apply \
  --dry-run=server -f azure-secret-store.yaml
kubectl --context "$KUBE_CONTEXT" apply -f azure-secret-store.yaml
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" \
  wait secretstore/qodo-secrets --for=condition=Ready --timeout=120s

Apply the shared database ExternalSecret. For ordinary Key Vault secrets, remoteRef.key: qodo-database selects the Secret; secret/qodo-database is also an explicit Secret-type reference. Its property: POSTGRES_PASSWORD extracts the JSON property and writes the fixed Kubernetes target. For more information, see Manage Qodo secrets with External Secrets Operator. Verify the ExternalSecret’s ready condition, refresh timestamp, target name, and key names. After source rotation, confirm the target updates before rolling out its consumer, then check that the relevant Qodo flow works. A schema or dry-run success does not establish that Azure accepts the federated identity or permits vault access.

Troubleshoot Azure access

Symptom	Check and recovery
Token exchange fails	Check the OIDC issuer, federated subject/audience, service account annotations, and selected identity
The vault returns an access denial	Check the vault’s RBAC or access-policy mode and data-plane Secret read permissions
The source cannot be found	Check the vault URL, Secret name, enabled source version, and case-sensitive JSON property
Requests time out	Check vault firewall/private endpoint policy, DNS, and access from ESO to token and vault endpoints

Next steps

Manage Qodo secrets with External Secrets Operator: Apply the shared ownership, rotation, and recovery procedure.
Azure Key Vault provider: Review other authentication patterns and object types.

Helm charts

Operations

Git Integration

Before you begin

1. Prepare the vault Secret and permissions

2. Configure the service account and store

3. Reconcile and verify

Troubleshoot Azure access

Next steps

​Before you begin

​1. Prepare the vault Secret and permissions

​2. Configure the service account and store

​3. Reconcile and verify

​Troubleshoot Azure access

​Next steps

Before you begin

1. Prepare the vault Secret and permissions

2. Configure the service account and store

3. Reconcile and verify

Troubleshoot Azure access

Next steps