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