Configuration

All example configurations are embedded in the binary:

vault.svc config list                    # list embedded examples
vault.svc config generate bootstrap      # print one to stdout
vault.svc config generate bootstrap -d . # write to a directory

Server bootstrap file

Default path /etc/vault/vault.yaml, selected with -f.

Production shape (HCP Vault backend, in-process signer):

/etc/vault/vault.yaml

vaultmanager:
  store:
    hcpvault:
      url: https://vault.internal:8200
      certpath: /etc/vault/certs/client.crt
      keypath: /etc/vault/certs/client.key
      cacertpath: /etc/vault/certs/ca.crt
      authname: vault-cert
      secretspathprefix: secret
      certificatespathprefix: kisaicerts
      retryduration: 5s
vault:
  signer:
    type: inproc
servicejwt:
  expiry: 1h
  httponly: true
vault:
  client:
    transport: remote
accessrules: {}

Development shape (plaintext file store — refuses env: prod):

vaultmanager:
  store:
    fsvault:
      filepath: ./vault-data.yaml
      env: dev

Storage backends

Selected by the key under vaultmanager.store.<type>:

Backend	Notes
hcpvault	HashiCorp Vault KV-v2. Production default. Needs cert auth + policy set up once (see Operations)
openbao	Wire-compatible with hcpvault
azurekv, awssm	Azure Key Vault / AWS Secrets Manager — preview
fsvault	Plaintext YAML on disk. Development only

Signers

Selected by vault.signer.type — this decides where CA and JWT signing keys are custodied. The key never leaves the signer; Vault only requests signatures.

Signer	Config block
inproc	Key material on disk (default)
pkcs11	pkcs11: {module_path, slot_id, pin_env, key_label}
awskms	awskms: {key_id, region}
azurekv-keys	Azure Key Vault keys
gcpkms	Google Cloud KMS

Generate a starting point with vault.svc config generate signer-<type>.

Key configuration knobs

Read from cluster config at runtime:

Key	Default	Purpose
vault.enforce_caller_cpet	true	Deny tenant-scoped ops whose caller CPET doesn’t match the secret’s scope. false = warn-only. Fails closed if unresolvable
vault.envelope.enabled	false	Per-tenant envelope encryption of secret values
vault.envelope.master	—	Master key for the built-in KEK derivation (dev/test; use a KMS provider in production)
vault.signer.type	inproc	Signing custody (see above)
audit.endpoint	—	Audit sink URL (e.g. https://audit.internal:8443/submit). Unset = local log only
servicejwt.expiry	1h	Service JWT lifetime
workloadjwt.expiry	—	Workload JWT lifetime
spiffe.trust_domain	kis.ai	SPIFFE trust domain in issued identities
middleware.operator.role_enforcement.enabled	false	Enforce operator roles from cert SANs
mode	nonroot	root = this instance is the vault (wires an in-process client for its own needs)
zerotrust	—	mTLS posture, as everywhere on the platform
secrets.validity	—	Default secret validity window (e.g. 2160h)

Access rules

JavaScript rules evaluated per entity/action. Rule inputs: from_dc, from_cluster, from_service (from the caller’s certificate), from_customer/from_product/from_env/from_tenant (propagated CPET), secrets.* / certificates.* (the stored record), requestor.* (the request payload).

accessrules:
  secrets:
    internal:
      access:
        read:
          language: js
          rules:
          - from_service == secrets.service || from_service == 'iam'

Field-filter rules return arrays — e.g. a certificate read rule can return ["cert","key"] for the owner but ["cert"] for everyone else, which is how private keys stay private.

The dev profile ships permissive - "true" rules; never carry those to production.

Agent configuration

/etc/vault/agent.yaml on each node:

agent:
  node_name: node-01
  trust_domain: kis.ai
server:
  address: https://vault.internal:7999
listeners:
  vault:
    socket: /run/vault/vault.sock
data_dir: /var/lib/vault
metrics:
  listen: 127.0.0.1:9099
behavior:
  cert_renewal_threshold: 0.5   # renew node cert at half-life
security:
  use_tpm: false

file_deliveries can additionally materialize credentials as files for workloads that can’t speak the socket protocol.