I want to give the users the possibility store their secrets inside of Vault in a way that even someone with a root token couldn’t encrypt them. I guess Cubbyhole would fit into that description but I don’t want the users to loose their data after logout.
Transit could be another way but in that case the users would need to securely store the given ciphertext and that would be quite inconvenient.
How can it be done?
Hi Eugen,
Both secrets engine that you mentioned, cubbyhole and transit, are good and valid ways of protecting data. The cubbyhole secrets engine provides a way to silo data that is only bound and accessible to its token. Secrets in the cubbyhole backend expires when the token gets expired (which is the case for any lease-based secret engine) and not after a particular log out, say from the UI. The transit secrets engine’s encrypt/decrypt operations are path-based so with proper ACLs you can restrict who is allowed to do these operations with a particular key. However, this would not prevent a root token from performing these operations as it would have access to these paths as well.
Generally, data can be properly protected with the correct ACL policies to prevent unintended access. With regards to the root token having unrestricted access, the recommendation is to actually never keep one around in production environments, and to revoke the initial root token once everything has been set up. If one is ever needed, it can be generated with the unseal/recovery keys, but this would require consensus from the a quorum of key owners so that no single person can access protected data.
Ok, I see. That’s what I’ve expected.
Thank you.