Backups of the encryption keys

Three products encrypt part of what they store, each with a key that is not in its database. A database backup restored without the matching key is unreadable: the encrypted data in it is lost for good.

These three keys are the only things in the platform you must keep an offline copy of. Everything else can be made again: passwords and client secrets are simply issued anew.

Product	Key	Where it lives	Without it
TinyGuard	the encryption key in its secrets file (secrets.toml)	the Secret tinyguard-secrets	stored provider secrets and other sealed values cannot be read
TinyVault	the root key file (keys)	the Secret tinyvault-keys	every stored secret value is unreadable
TinyConductor	the signing-key encryption key (CONDUCTOR_SIGNING_KEY_ENCRYPTION_KEY)	a Secret you name in its chart; in Bundled mode, generated into its data volume	its stored token signing keys cannot be read; tokens it issued stop working

When to copy them

• Right after you create them, before the first install of each product.
• After every rotation of one of them, before the old one is retired.
• Keep the copy with your database backups, but not in the same place: for example in a password manager or a sealed offline store, so that one stolen backup does not hold both the data and its key.

Copying them out of the cluster

kubectl -n tinyblox get secret tinyguard-secrets -o jsonpath='{.data.secrets\.toml}' | base64 -d > tinyguard-secrets.toml
kubectl -n tinyblox get secret tinyvault-keys -o jsonpath='{.data.keys}' | base64 -d > tinyvault-keys

TinyConductor’s key is wherever you created it; in Bundled mode, copy the engine’s data directory with the volume.

Move the files straight into your offline store and delete the local copies.

Restoring

1. Recreate each key’s Secret from the offline copy, under the same name.
2. Restore the database backups.
3. Install each product at the version the backup was taken with.

TinyVault checks its root key file when it starts: with the wrong file it stays not ready and says so, and it never creates a new root key on its own.

Using a key service instead

Instead of a key file, TinyVault can keep its root key in a cloud key service (AWS KMS, Google Cloud KMS, Azure Key Vault) or in HashiCorp Vault, and TinyGuard can keep its key-encryption key in HashiCorp Vault. The key then never leaves that service, and its own backup and access rules apply: there is no file for you to copy. Each product’s guide describes the settings.

Rotation

TinyGuard and TinyVault rotate their keys without losing data: a new key is added, the stored data is re-encrypted under it, and the old key is retired only after the backups that need it have expired. Rotation of TinyConductor’s key is coming. Rotation happens only when you start it; see each product’s guide and Platform secrets.