Encrypting files at rest for the filesystem target

[dosisod]

What is the problem you want to solve?

I want to be able to use the filesystem target in production, but since the keys are not encrypted at rest, it would be insecure to do so. Also, the docs specifically recommend to not use the filesystem in production.

How do you want to solve it?

Encrypt keys and other sensitive data at rest. I don't know what it would take to accomplish this, but at the very least I imagine a private key or asymmetric key would have to be provided at startup to unlock the files.

Additional context

1. Are there alternative solutions?

Yes, using a 3rd party KMS (ie AWS or GCP) or self-hosting a KMS like Vault. The issue with these solutions is that it requires you to become dependent on a 3rd party for hosting, pricing, availability, etc. The next best solution for me is to use Vault, but considering the Business Source Licensing fiasco they're in I don't know if I can use their product for my company. This is me just being picky, all else fails I can (and probably will) just chose one of these 3rd parties as my primary KMS.

I love that KES is AGPLv3 licensed, but (in my opinion) that freedom gets diminished when you have to use proprietary and/or 3rd party as your source of truth. If KES could be it's own source of truth this would allow you to use it as your primary KMS, which would be great for small applications and on-prem deployments.

2. Would your solution cause a major breaking API change?

For the filesystem target, yes. Alternatively we could create a new "secure filesystem" target, and then keep the existing filesystem target.

3. Anything else that is important?

I'm planning on using KES for a single application in a self-hosted environment, and thus won't be needing/using the scalability of KES: I like that KES is minimal and has an easy to use API, something that most/all KMS systems I've looked at don't seem to have. I understand that adding encryption at rest would make it such that KES cannot be scaled horizontally, and this might go against the goals of KES. I'm mainly opening this issue to see if you would consider this path in the first place, and if so, what sort of effort it would take to accomplish.

Thanks!

[klauspost]

You fail to describe the critical part - how should the key to stored data be stored? An external KMS seems silly. As startup envs? Well, you'd still need it to store it somewhere on the system. TPM? Still doesn't protect if hardware is stolen. A startup prompt? Hardly realistic for a server.

At some point KES needs to have access to the raw data. If KES has access to it, so does potentially anyone with access to the hardware. So there are no "easy" solution - and I don't see anything not already covered by storing data on an encrypted partition.

[dosisod]

I agree that storing any encryption key along side the encrypted data would be pointless and insecure. For reference, self-hosted instances of Vault require an "unseal key" to unlock the data whenever it is started. Quoting from the docs:

Every initialized Vault server starts in the sealed state. From the configuration, Vault can access the physical storage, but it can't read any of it because it doesn't know how to decrypt it. The process of teaching Vault how to decrypt the data is known as unsealing the Vault.

Unsealing has to happen every time Vault starts. It can be done via the API and via the command line ...

(Emphasis mine).

So yes, while it may be "impractical", it is the most secure option. For a short lived container this might be annoying/impractical, but for a long-lived physical server this is less of an issue.

And to your point of using an encrypted partition: If using an encrypted partition is sufficient to secure data stored in the filesystem target, why does the documentation specifically say it is insecure to use it in produciton? If I'm running KES on a separate server that has strict access controls, can only be communicated with via the KES API, and uses an encrypted partition or full-disk encryption, then is it fair to say that the filesystem backend would be secure?

[derSascha]

Some simple setup might use a network mount that contains the key (e.g. via sshfs), or download the encryption key to a tmpfs on startup. Both are comparable simple to set up, compared to automatic unlocking a vault instance or encrypted disk after reboot. This setup has the benefit that the encrypted data, the keys in the store, and the encryption key are stored at different places. If required, the access to encryption key can be locked.

Compared to a cloud KMS, it might be less secure, but compared to the plaintext file system store, more secure.

Created a pull-request with an implementation that wraps the existing file system store, and uses the existing secret key to encrypt the data. On smaller setups, this might be very helpful to reduce the cost and avoids manual unlocking.