Secrets And Vault

Supernode is opinionated about secrets.

The canonical model is Vault plus Vault Secrets Operator.

Why this is the default

For SPO workflows, normalizing on ad hoc Kubernetes secrets is not enough. Producer-style workloads need a controlled path for distributing runtime material while keeping cold and high-risk assets out of the cluster.

Supernode therefore expects operators to:

• store runtime material in Vault
• let workloads reference shared Vault auth through the control-plane
• let Vault Secrets Operator sync namespace-local Kubernetes secrets only where needed

The default split is:

• kv/runtime/... for workload-readable runtime material
• kv/operator/... for operator-only material that the shared supernode auth cannot read

Shared auth model

The control-plane creates a shared VaultConnection and VaultAuth in the control-plane namespace.

The canonical reference for workloads is:

vaultAuth:
  ref: control-plane/default

This is the expected default for Supernode workloads.

That shared auth is intentionally read-only and only covers kv/runtime/.... It does not grant pods access to kv/operator/....

Producer runtime material

For Cardano and Apex Fusion producer flows, the runtime material that belongs in Vault is:

• kes.skey
• vrf.skey
• op.cert

The material that should stay outside the cluster includes:

• cold keys
• operational certificate counters
• other operator-only signing assets

Canonical runtime path example:

kv/runtime/cardano-node/mainnet-mypool/block-producer

If an operator deliberately wants semi-cold storage in Vault, use a salted operator path such as kv/operator/cardano-node/mainnet-mypool-7f3c9d2a8e4b1f6c/....

Canonical workflow

1. bootstrap the control-plane
2. initialize and unseal Vault if needed
3. run post_install.sh
4. write runtime material into Vault
5. configure the workload with the appropriate vaultStaticSecret.path
6. validate that VSO synced the namespace-local Kubernetes secret

Example:

vault kv put kv/runtime/cardano-node/mainnet-bp/block-producer \
  kes.skey=@kes.skey \
  vrf.skey=@vrf.skey \
  op.cert=@op.cert

For some operators, storing private material in kv/operator/... is a stronger choice than leaving it on a normal filesystem without meaningful protections. That can be a reasonable semi-cold compromise. The ideal custody model for cold keys is still separate offline or air-gapped devices.

Cloud seal modes

The preferred Supernode approach is to use cloud-native auto-unseal where available:

• AWS: awskms
• GCP: gcpckms
• Azure: azurekeyvault
• OCI: ocikms

For local and bare-metal evaluation, shamir or controlled transit patterns remain valid.

For agent-guided maintenance flows that apply this model safely, use:

• cardano-spo-maintenance-overview.md
• cardano-spo-kes-rotation.md
• cardano-spo-pool-update.md
• cardano-spo-pool-retirement.md