I appreciate the concept behind Chef Vault and I think a vault like storage for secrets like certificates and passwords is a much needed addition to Chef infrastructure.
When I was evaluating Vault recently, I had concerns about how much real security it provides. In reading the implementation, it appears that this is only security by obfuscation and not truly more secure than regular encrypted data bags as you still must use the encrypted_data_bag_secret to unlock the key for the node you're operating on... you still have access to all of the secrets for all of the nodes, just not in a direct way. If someone were to compromise a node and retrieve the encrypted_data_bag_secret, you have just added 1 hoop to jump through for the attacker rather than adding more security. Maybe that'll save you, but this depends on the attacker not understanding how Vault works... not something I'd like to depend on.
Have you found this to be the case? My evaluation was cursory and probably not fully informed.
I think that, for something like Vault to work, I would need a server side component sitting in front of the encrypted data bags to handle access rights.
I really want something like Vault, but I want to provide a personal secret key to unlock the vault at run time so only the secrets I have access to get unlocked rather than giving everyone access to everything, having an additional layer keyed off node names as Vault does.
The solution, perhaps, would be that if I have access to perform a deploy, I provide my key and the deploy uses my access rights temporarily (holding my secret in memory during the chef run) to unlock the vault of secrets. Think torpedo launch keys: I put the key in and kick off the automated systems to fire the torpedo... or I put my private key in and kick off the automated systems to deploy my software.
For those running chef in daemon mode, perhaps when the chef-client daemon starts up, it can accept a key to hold in memory, which would be better than storing it in a file, though still perhaps not 100% secure. There are more concerns to figure out for daemon mode, hence this is all still theoretical.
Having to leave the key on the node (as we do currently) means that once a single node is compromised, the entirety of things encrypted with /etc/chef/encrypted_data_bag_secret are easily compromised.
Currently, encrypted data bags only give security if your chef server itself is compromised but they make people _feel_ like they are being more secure by using them... the general attack vector, however, is through nodes exposed to the public internet that have flawed applications running, not through the Chef server which is probably internal network access only. All of these nodes contain the encrypted_data_bag_secret.
As a result: encrypted data bags are not often any more secure than regular data bags for the general case and may inadvertently harm security due to the aforementioned feeling of security that encrypting data bags gives and so some active secret storage system would be very valuable... just something more substantial than Vault.
Thoughts?
Josiah