> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qodo.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Use Azure Key Vault

> Connect External Secrets Operator to Azure Key Vault with Microsoft Entra Workload ID.

* **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](https://docs.qodo.ai/on-prem/external-secrets.md).

## Before you begin

Complete the common ESO controller, webhook, CRD, namespace, and permission
checks first. For more information, see [Before you begin](https://docs.qodo.ai/on-prem/external-secrets.md#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](https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview).

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](https://external-secrets.io/latest/provider/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.

```yaml azure-secret-store.yaml theme={null}
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](https://external-secrets.io/latest/provider/azure-key-vault/#referenced-service-account).

## 3. Reconcile and verify

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

```bash theme={null}
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](https://docs.qodo.ai/on-prem/external-secrets.md).

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](https://docs.qodo.ai/on-prem/external-secrets.md): Apply the shared ownership, rotation, and recovery procedure.
* [Azure Key Vault provider](https://external-secrets.io/latest/provider/azure-key-vault/): Review other authentication patterns and object types.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.