Configure Azure Key Vault

Azure Key Vault is the primary secret backend for a Kirimana control plane running on AKS. Secrets — the Databricks service-principal token, connection credentials, REST auth headers — live in Key Vault, and kiri.yml references them by name. Nothing sensitive lands in the repo, and nothing sensitive is copied into Kirimana’s own storage: refs resolve at run time, straight from the vault.

How refs resolve

A ${vault:…} ref names a secret id and a key. Key Vault stores each secret as a single string, so the common case asks for the sentinel key value:

targets:
  prod:
    adapter: databricks
    token: "${vault:databricks-prod-token:value}"

If a secret in Key Vault holds a JSON object rather than a plain string, you can request a key inside it — ${vault:db-creds:password} pulls password out of the JSON blob. Key Vault secret names allow only alphanumerics and -, so Kirimana maps a namespaced id like prod/postgres/dw to prod-postgres-dw before the API call; your YAML keeps the portable /-style id and the translation happens for you.

Workload-identity binding on AKS

In production, Kirimana authenticates to Key Vault by workload identity — no secret-zero, no bootstrap token on disk. The pod’s Kubernetes service account is federated to a managed identity, and that identity is granted read access to the vault. Authentication follows Azure’s standard credential chain: managed identity in the cluster, az CLI login for local development, and a service principal via AZURE_CLIENT_ID / AZURE_TENANT_ID / AZURE_CLIENT_SECRET in CI.

The kirimana deploy flow wires this binding chain for you when it provisions the control plane — AKS to Key Vault to the Databricks service principal — so the pod that runs your applies can read the SP token without a human ever handling it. See the AKS deploy guide for the end-to-end provisioning path.

Storing values

Put a value into the vault through the CLI rather than the portal, so it never lands in shell history. Interactive use prompts for the value:

kiri vault set databricks-prod-token --key value

In CI, pass the value through an environment variable — the source variable is read and then deleted from the process after writing:

SP_TOKEN=… kiri vault set databricks-prod-token --key value --from-env SP_TOKEN

--force overwrites an existing entry without asking. To see which <id>:<key> pairs exist without printing any values, list them:

kiri vault list

Diff that listing against the refs your YAML declares to confirm every ref has a value behind it.

Rotation

Rotation is a re-set over the same key with --force. Because the ref is indirection, the new value takes effect on the next run — no YAML change, no redeploy:

kiri vault set databricks-prod-token --key value --force

Transient Key Vault failures — a 5xx, a network blip, a request timeout — are retried under a bounded policy before a read is allowed to fail, so a momentary hiccup does not by itself break an apply. Authentication and not-found errors propagate immediately, because retrying those never helps.

Azure Key Vault is available today in the v1.0.0-beta.1 private beta and is the recommended backend for AKS-hosted deployments.