Secrets

Secrets keeps credentials — API keys, passwords, connection strings, certificates — in vaults, and hands them to workloads when they start, so the values never appear in a resource's configuration. Settings that are not sensitive belong in the resource's own app settings; a vault is for what must not leak.

Vaults and secrets

• A vault is a resource in a resource group. Its name is also its address, so it is unique across the whole platform, not just your boundary.
• A secret is a named entry in a vault. Writing a value creates a new version; exactly one version is current and the older ones stay readable.
• A secret can be disabled: it keeps its versions, but nobody can read it.
• A deleted secret is kept and can be recovered — see Delete, recover and purge.

How values are protected

Every value is encrypted with AES-256-GCM under a key that belongs to its vault. That vault key is itself encrypted with the platform's master key and kept outside the database; the database holds only metadata and ciphertext. Listing secrets and reading their values are separate permissions, and reads of values are recorded in the vault's activity log. Operators can read how the keys are kept in Key hierarchy.

How workloads get their secrets

Apps, functions and container instances reference a secret by vault and secret name. When a pod starts, an init container fetches the current values with the workload's own identity and hands them to the application; nothing is written to disk. The details differ per workload — see Use secrets in workloads.

Pages

• Vaults — the vault page, activity and deleting a vault
• Create a vault
• Manage secrets
• Use secrets in workloads
• Permissions
• Names and limits