Skip to main content
Private Preview·Early access by invitation.Request access →
Kirimana.
Docs · Vaults

Configure AWS Secrets Manager

AWS Secrets Manager is a supported secret backend for Kirimana. It sits behind the same ${vault:…} reference machinery as every other backend, so kiri.yml looks identical whether a secret ultimately lives in Secrets Manager, Azure Key Vault, or a Databricks scope — the only thing that changes is which store the ref resolves against.

What the vault abstraction guarantees

Every backend Kirimana supports implements one small contract: given a secret id and a key, return the plaintext value. That single guarantee is what lets your project YAML stay portable.

  • Refs are indirection. YAML carries ${vault:<id>:<key>}, never a value. Rotating a credential is a re-write at the store; no YAML edit, no redeploy.
  • JSON and plain-string secrets both work. A secret stored as a JSON object lets you request a key inside it — ${vault:db-creds:password} pulls password out of the blob. A secret stored as a plain string is read with the sentinel key value: ${vault:api-token:value}.
  • No secret is copied into Kirimana’s storage. Reads are forwarded to the backend and held in memory only for the run, cached per-process so the same secret isn’t fetched repeatedly during one apply.
  • Failures are typed, not swallowed. A missing key reports the keys that are present; a fetch failure names the secret id it could not read.

Because the abstraction is uniform, everything you already know about writing refs, listing them with kiri vault list, and rotating by re-set applies to Secrets Manager unchanged.

Refs against Secrets Manager

A JSON secret in Secrets Manager exposes its inner keys directly:

targets:
  prod:
    adapter: databricks
    token: "${vault:databricks/prod:token}"

Here databricks/prod is the Secrets Manager secret id and token is a key inside the JSON payload. If instead the secret is a plain string, ask for value:

value_ref: "${vault:crm/api:value}"

Reads authenticate with the AWS credential chain in the environment Kirimana runs in — an instance or pod role in production, your local profile in development — and target the region the backend is configured for. The AWS integration is an optional install; a control plane that reads from Secrets Manager pulls in the AWS SDK as an extra rather than carrying it by default.

Where to go next

The AWS Secrets Manager backend exists and resolves refs today at v1.0.0-beta.1. The operational specifics — the exact IAM policy the reader role needs, region and cross-account configuration, and the provisioning steps for an AWS-hosted control plane — are maintained in the product repository’s deployment docs, which stay in lockstep with the backend code. For the ref conventions, listing, and rotation that are common to every backend, the secrets and vault reference is the canonical page; this page covers only what is specific to Secrets Manager. Kirimana is in private beta; deployment support is invitation-gated.

Updated 5 July 2026 · v1.0.0-beta.1