Changes

• harp server vault
  • Support --transformer keyName:key where key is generated from harp keygen to expose a transformer as a Vault Transit encryption backend.

Samples

Expose transformers using Vault Transit backend API.

harp server vault \
  --transformer fernet:$(harp keygen fernet) \
  --transformer aes-256:$(harp keygen aes-256) \
  --transformer secretbox:$(harp keygen secretbox)

You can use vault cli to encrypt or decrypt a secret :

$ export VAULT_ADDR=http://127.0.0.1:8200
$ vault write transit/encrypt/<keyName> plaintext=$(base64 <<< "my secret data")
Key           Value
---           -----
ciphertext    vault:v1:66hL0lIX0lXHFD6sDsl07ztaDStDrJLL7mKGei3zlups6cllARcUec7P4kg4JaA23AEqkNNGqg==

Then to decrypt :

$ export VAULT_ADDR=http://127.0.0.1:8200
$ vault write -format=json transit/decrypt/secretbox ciphertext=vault:v1:66hL0lIX0lXHFD6sDsl07ztaDStDrJLL7mKGei3zlups6cllARcUec7P4kg4JaA23AEqkNNGqg== \
    | jq -r ".data.plaintext" \
    | base64 -D
my secret data

This does not pretend to replace a full-featured Vault cluster, just expose using Vault compatible API a limited set of features at the bootstrap time during a deployment usable with Vault CLI, while Vault cluster is not deployed yet.
Once deployed, VAULT_ADDR just need to point to real Vault cluster at showtime.

Changes

• CSO
  • Add global region alias to support region unbounded secrets
  • Add local provider to infrastructure ring

Changes

• Secret value is encoded using a compound ASN.1 sequence to allow future improvements;
• Vault support nested JSON value inserted via UI only, but not via CLI => Harp enforces simple secret key/value as 'string => string' to prevent nested secret tree where the user should dispatch secret across the secret tree. This produces an error on vault import, this error is now logged;

Golang 1.15.6

Golang 1.15.6