ROUTE SENSITIVE FIELDS TO SPECIFIC VAULTS

This guide shows you how to control which vault receives sensitive field values when a model method runs. By default, Swamp stores sensitive fields in the first available vault. When you have multiple vaults — for example, separate backends for production and development secrets — you can direct fields to specific vaults at two levels: the repository and the individual model definition.

Prerequisites

Two or more vaults configured in the repository:

$ swamp vault create local_encryption prod-secrets

INF vault·create: Created vault: "prod-secrets" ("Local Encryption")

$ swamp vault create local_encryption dev-secrets

INF vault·create: Created vault: "dev-secrets" ("Local Encryption")

Set a default vault for the repository

Add defaultVault to .swamp.yaml:

defaultVault: prod-secrets

All sensitive resource output fields now store in prod-secrets unless a field-level or spec-level override directs them elsewhere.

defaultVault also applies to swamp serve OAuth token storage and device authorization token storage.

Override per resource in a model definition

To route a specific resource's sensitive fields to a different vault, add a resources block to the model definition YAML. Each key matches the name of a ResourceOutputSpec declared by the model type.

To find the available resource spec names for a model type:

$ swamp model type describe <type>

Then add the override in the definition file:

type: "@acme/cloud-provisioner"
name: my-provisioner
globalArguments:
  region: us-east-1
resources:
  credentials:
    vaultName: prod-secrets
  config:
    vaultName: dev-secrets

In this definition, sensitive fields in the credentials resource store in prod-secrets, while those in config store in dev-secrets.

Verify which vault received a secret

After running a method that produces sensitive output, check that secrets landed in the expected vault:

$ swamp vault list-keys prod-secrets

INF vault·list-keys: Vault "prod-secrets" ("local_encryption"): 2 key(s)
INF vault·list-keys:   - "acme-cloud-provisioner-abc-provision-accessKey"
INF vault·list-keys:   - "acme-cloud-provisioner-abc-provision-secretKey"

Resolution order

The full precedence chain is:

1. Field-level vaultName (set by the extension author in TypeScript)
2. Spec-level vaultName (set by the extension author, or overridden via resources.<specName>.vaultName in the definition YAML)
3. Repo-level defaultVault in .swamp.yaml
4. First available vault

Refer to the vault resolution order reference for details on each level.