AirLock: The Hard Part of Vault Secret Migration

How I designed a controlled plaintext boundary for static secrets that genuinely have to move

The application stays in the house.
Vault changes the locks, replaces the keys, and invalidates the old ones.
AirLock moves the valuables that cannot be regenerated.

I did not set out to build AirLock.

I was working on a different question: can a running application change the Vault it trusts without moving the application itself?

Goldie Locks, my lab for that question, moves a small CRUD application from a Vault Community (OSS) root namespace to the `app-production/` namespace of an independent Vault Enterprise cluster, and then back again. The application keeps running the whole time. Vault Enterprise is never stopped, sealed or retired, not even on the way back.

For most of the application’s trust, the migration was cleaner than I expected. Certificates could be reissued. Database credentials could be regenerated. Transit-protected records could be decrypted by one Vault and encrypted by the other. Policies, roles and engines could be recreated.

Then I reached static KV, and the model stopped being clean.