armon
commented
5 years ago @justincampbell I suggest a slightly different approach here, which is to use Vault's ability to have derived keys. (https://www.vaultproject.io/api/secret/transit/index.html#derived).
The documentation is a bit subtle here, and I will nudge the Vault team. In essence, there are concrete keys that Vault needs to hold on to, those are the named keys in the transit backend, anything like "transit/keys/foo". For each key we need to hold on to some meta data, and there is some upper bound of reasonable keys to manage (16K, maybe 32K), but not unlimited.
My concern with doing a dynamic key per record is you can quickly force Vault into having millions of keys. To handle this, Vault supports derived keys. These are keys that aren't stored, but are dynamically derived from a unique context.
The common pattern is to use a concrete base key, such as "foo". From there, you provide a unique context, maybe a user UUID or something, which derives a sub key from foo. That key is then used to perform the operation and then thrown away. This way, Vault only needs to manage a reasonable number of physical keys.
I would recommend using that, since otherwise we run the risk of creating an enormous number of keys in Vault.
justincampbell
This adds support for dynamically computing a transit key name on each encrypt/decrypt request, which allows an application to use a separate key per record, or using an encryption key per belongs_to relation.