Secret Management

Secret Management is an enterprise-only feature. It requires the enterprise Bifrost image and a PostgreSQL config store.

Connect an external secret manager so provider keys and other credentials are never stored in Bifrost’s database. Configure vaultStore under storage.configStore in your values file. Once connected, any secret field in your values file accepts a vault.<path> reference in place of a plaintext value or env.* reference. See Secret Management for the full list of supported fields, access modes, and secret rotation.

Configuration

AWS Secrets Manager
GCP Secret Manager
HashiCorp Vault
Azure Key Vault

IAM role (recommended)
Static credentials
Role assumption

Attach an IAM role to your pod via IRSA and leave credentials unset - the AWS SDK inherits the role automatically.

storage:
  configStore:
    vaultStore:
      enabled: true
      type: aws-secrets-manager
      prefix: bifrost
      accessMode: read_only
      aws:
        region: us-east-1

storage:
  configStore:
    vaultStore:
      enabled: true
      type: aws-secrets-manager
      prefix: bifrost
      accessMode: read_only
      aws:
        region: us-east-1
        accessKeyId: env.AWS_ACCESS_KEY_ID
        secretAccessKey: env.AWS_SECRET_ACCESS_KEY

accessKeyId and secretAccessKey must be set together.

Assume a cross-account or restricted IAM role on top of any existing credential source.

storage:
  configStore:
    vaultStore:
      enabled: true
      type: aws-secrets-manager
      prefix: bifrost
      accessMode: read_only
      aws:
        region: us-east-1
        roleArn: arn:aws:iam::123456789012:role/BifrostSecretsReader

AWS fields

Field	Required	Description
`region`	No	AWS region (e.g. `us-east-1`). Falls back to `AWS_DEFAULT_REGION` or instance metadata if unset.
`accessKeyId`	No	Required when not using IAM roles. Must be set with `secretAccessKey`.
`secretAccessKey`	No	Must be set with `accessKeyId`.
`sessionToken`	No	For STS-issued temporary credentials.
`roleArn`	No	IAM role to assume via STS.
`kmsKeyId`	No	KMS key for encrypting new secrets (`read_and_write` only).

Workload Identity (recommended)
Service account key

Bind a GCP service account to your GKE pod and omit credentials - ADC is used automatically.

storage:
  configStore:
    vaultStore:
      enabled: true
      type: gcp-secret-manager
      prefix: bifrost
      accessMode: read_only
      gcp:
        projectId: my-gcp-project

storage:
  configStore:
    vaultStore:
      enabled: true
      type: gcp-secret-manager
      prefix: bifrost
      accessMode: read_only
      gcp:
        projectId: my-gcp-project
        credentialsJson: env.GCP_CREDENTIALS_JSON

credentialsJson accepts a JSON string (the full key file contents) or a file path on disk.

GCP fields

Field	Required	Description
`projectId`	Yes	GCP project containing your secrets.
`credentialsJson`	No	Service account key JSON string or file path. If omitted, Application Default Credentials are used.

Bifrost uses the KV v2 secrets engine. Auth is resolved in order: explicit token → AppRole → Kubernetes auth → ambient VAULT_TOKEN env var.

Token
AppRole
Kubernetes
Ambient token

storage:
  configStore:
    vaultStore:
      enabled: true
      type: hashicorp-vault
      prefix: bifrost
      accessMode: read_only
      hashicorp:
        address: https://vault.internal:8200
        token: env.VAULT_TOKEN

storage:
  configStore:
    vaultStore:
      enabled: true
      type: hashicorp-vault
      prefix: bifrost
      accessMode: read_only
      hashicorp:
        address: https://vault.internal:8200
        mountPath: secret
        roleId: env.VAULT_ROLE_ID
        secretId: env.VAULT_SECRET_ID

Log in with the Bifrost pod’s service account token through Vault’s Kubernetes auth method, so no Vault token or AppRole secret is stored in the cluster.

serviceAccount:
  create: true
  name: bifrost

storage:
  configStore:
    vaultStore:
      enabled: true
      type: hashicorp-vault
      prefix: bifrost
      accessMode: read_only
      hashicorp:
        address: https://vault.internal:8200
        kubernetesRole: bifrost

The Vault role must be bound to the chart’s service account and the release namespace:

vault write auth/kubernetes/role/bifrost \
  bound_service_account_names=bifrost \
  bound_service_account_namespaces=<release-namespace> \
  token_policies=bifrost-read \
  token_ttl=1h

Keep serviceAccount.automount: true (the default) so the token is mounted at the default path. See Secret Management for enabling the auth method and the bifrost-read policy.

If VAULT_TOKEN is set in the environment and no token, AppRole, or Kubernetes role is configured, Bifrost inherits it automatically. Useful with Vault Agent injection.

storage:
  configStore:
    vaultStore:
      enabled: true
      type: hashicorp-vault
      prefix: bifrost
      accessMode: read_only
      hashicorp:
        address: https://vault.internal:8200

HashiCorp fields

Field	Required	Description
`address`	No	Vault server URL. Reads `VAULT_ADDR` env var if unset.
`token`	No	Vault token.
`namespace`	No	Vault namespace (HCP Vault / Vault Enterprise).
`mountPath`	No	KV v2 mount path. Defaults to `secret`.
`roleId`	No	AppRole role ID. Must be set together with `secretId`.
`secretId`	No	AppRole secret ID. Must be set together with `roleId`.
`kubernetesRole`	No	Vault role for Kubernetes auth. Setting it enables login with the pod’s service account token.
`kubernetesMountPath`	No	Mount path of the Kubernetes auth method, without the `auth/` prefix. Defaults to `kubernetes`.
`kubernetesTokenPath`	No	Path to the service account token file. Defaults to `/var/run/secrets/kubernetes.io/serviceaccount/token`.

With clientId and clientSecret set, Bifrost authenticates as that service principal. Otherwise it uses DefaultAzureCredential, which picks up AKS Workload Identity, a managed identity, or AZURE_* environment variables.

Workload Identity (recommended)
Service principal

Federate a user-assigned managed identity with the chart’s service account, then annotate the service account with the identity’s client ID and label the pod so the Workload Identity webhook injects the token:

serviceAccount:
  create: true
  name: bifrost
  annotations:
    azure.workload.identity/client-id: "<managed-identity-client-id>"

podLabels:
  azure.workload.identity/use: "true"

storage:
  configStore:
    vaultStore:
      enabled: true
      type: azure-key-vault
      prefix: bifrost
      accessMode: read_only
      azure:
        vaultUrl: https://my-bifrost-kv.vault.azure.net

The federated credential’s subject must be system:serviceaccount:<release-namespace>:bifrost, matching serviceAccount.name. The webhook injects AZURE_CLIENT_ID, AZURE_TENANT_ID, and the projected token into the pod, so leave tenantId, clientId, and clientSecret unset. See Secret Management for creating the identity, federated credential, and role assignment.

Do not set an AZURE_CLIENT_SECRET env var on the Bifrost pod (for example through envFrom for an Azure provider key). DefaultAzureCredential would use it ahead of Workload Identity and Key Vault access would fail.

storage:
  configStore:
    vaultStore:
      enabled: true
      type: azure-key-vault
      prefix: bifrost
      accessMode: read_only
      azure:
        vaultUrl: https://my-bifrost-kv.vault.azure.net
        tenantId: env.AZURE_TENANT_ID
        clientId: env.AZURE_CLIENT_ID
        clientSecret: env.AZURE_CLIENT_SECRET

clientId and clientSecret must be set together, and tenantId is required with them.

Azure fields

Field	Required	Description
`vaultUrl`	Yes	Key Vault URI, for example `https://<vault-name>.vault.azure.net`. Must be `https`.
`tenantId`	No	Microsoft Entra tenant ID. Required when `clientId` and `clientSecret` are set.
`clientId`	No	Service principal client ID. Must be set together with `clientSecret`.
`clientSecret`	No	Service principal client secret. Must be set together with `clientId`.

Required role: Key Vault Secrets User for read_only, Key Vault Secrets Officer for read_and_write.Key Vault secret names allow only letters, digits, and -. Reference your own secrets by their exact name (vault.openai-api-key). A path containing /, _, or . is encoded to a different name, as described in Azure Key Vault secret names.

Common fields

These apply regardless of backend:

Field	Required	Description
`enabled`	Yes	Enable vault integration.
`type`	Yes	Backend: `aws-secrets-manager`, `gcp-secret-manager`, `hashicorp-vault`, or `azure-key-vault`.
`prefix`	No	Path prefix for Bifrost-managed secrets. Defaults to `bifrost`.
`accessMode`	No	`read_only` (default) - resolve refs only. `read_and_write` - also auto-store plaintext values and delete owned secrets on removal.

Credential fields inside vaultStore (for example token, kubernetesRole, vaultUrl, clientSecret) accept a plain value or an env.<VAR> reference. A vault.<path> reference does not work here, because these fields are read before the vault is connected.

Using vault references

Once configured, any secret field accepts a vault.<path> reference:

bifrost:
  providers:
    openai:
      keys:
        - value: vault.bifrost/providers/openai/key
          models:
            - gpt-4o
            - gpt-4o-mini

Full example

# vault-values.yaml
storage:
  configStore:
    type: postgres
    vaultStore:
      enabled: true
      type: aws-secrets-manager
      prefix: bifrost
      accessMode: read_and_write
      aws:
        region: us-east-1

bifrost:
  providers:
    openai:
      keys:
        - value: vault.bifrost/providers/openai/key
          models:
            - gpt-4o
            - gpt-4o-mini
    anthropic:
      keys:
        - value: vault.bifrost/providers/anthropic/key
          models:
            - claude-opus-4-8
            - claude-sonnet-4-6

helm install bifrost bifrost/bifrost -f vault-values.yaml

Managed Kubernetes

Hosted Containers

Config as Code

Enterprise Deployment

Common setup instructions

Secret Management

Configuration

AWS fields

GCP fields

HashiCorp fields

Azure fields

Common fields

Using vault references

Full example

​Configuration

​AWS fields

​GCP fields

​HashiCorp fields

​Azure fields

​Common fields

​Using vault references

​Full example

Configuration

AWS fields

GCP fields

HashiCorp fields

Azure fields

Common fields

Using vault references

Full example