Good point to bring up! On a similar note we found after using chef-vault internally in chef runs that it also had this nice side effect too. We now use it as a keepass replacement. Keeping passwords to systems/APIs in chef-vault items and storing them in source control, so you get versioning like you would in keepass. Keeping them in the chef-repo is also nice because now they are already there if you ever need them in a client run, and if not, then they’re in a location that easily accessible by all members of the team.
From: Maciej Pasternacki <email@example.com:firstname.lastname@example.org>
Reply-To: "email@example.com:firstname.lastname@example.org" <email@example.com:firstname.lastname@example.org>
Date: Tuesday, October 1, 2013 6:29 AM
To: "email@example.com:firstname.lastname@example.org" <email@example.com:firstname.lastname@example.org>
Subject: [chef] Re: Re: Re: Re: Chef Vault Writeup
This discussion focuses mostly on distributing secrets to nodes; chef-vault also allows to share secrets between users, encrypted by their private Chef API key. This can be quite convenient means to store secrets such as access keys to other APIs, confidential source data or shared secrets for plain old encrypted data bags, and so on - data that should be accessible to admins rather than directly to nodes. Chef-vault since version 2.0 supports key rotation - exchanging the secret - which lets us securely remove a user or node from the access list, and prevent them from seeing updated content.
Shameless Plug: I’ve just written a usable backend for git-annex (http://git-annex.branchable.com/) that stores files in a chef-vault data bag, encrypted for all the users with admin=true - it would also be possible to support various access levels for various items, for now it’s just a simple secret sharing mechanism. This way, once a teammate is registered with chef-server, they can just
git annex get all the keys they need straight into the chef-repo, which is quite convenient. Project is at https://github.com/3ofcoins/knife-annex
On 17 September 2013 01:09, Seth Falcon <email@example.com:firstname.lastname@example.org> wrote:
A few comments on Chef Vault, inline…
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.
Chef Vault helps you to solve the key distribution problem by taking
advantage of the RSA key pair assigned to each user and client on a Chef
Server. Encrypted data bags are used to implement it.
Here’s (my understanding of) what happens when you create a Chef Vault
item (encrypt a data bag item using Chef Vault):
You tell Chef Vault:
- the name of a vault (maps to a data bag)
- the name of an item (maps to a data bag item)
- secret item data
- the clients and users that should be able to access the secret
Chef Vault generates a random shared key and uses the encrypted data
bag support in Chef to encrypt the item data with this key.
Chef Vault uses the Chef API to obtain the public RSA keys of the
users and clients that should have access to item. It then encrypts
the shared key generated in #1 for each of the public keys. It stores
the user/client name to encrypted shared key in an $ITEM_keys data
bag item in the $VAULT data bag.
Here’s what I think this gives you:
Compared to vanilla encrypted data bags, you don’t have to arrange
for a shared seceret to be distributed to clients (nodes) and users
in your infrastructure.
If an attacker gains root access to a node, the attacker can decrypt
items that have been encrypted for that nodes client public
key. So an attacker would not have access to all of the secrets for
all of the nodes.
And some things it does not give you:
Nodes store the client private key on disk. Using this key to decrypt
secrets means compromise of the node will compromise any secrets
which can be accessed via that key. So no torpedo launch key
feature. In most cases, the secret data is used on a node in such a
way that root access to the node would mean compromise of that secret
regardless of how it was originally obtained. Avoiding that is hard.
If a node is compromised, you will need to do more than remove the
vault entry that encrypts the shared secret for the compromised key
pair. In fact, if an attacker is able to obtain old copies of the
encrypted data bag, changing the shared secret is not enough. You
will need to change your underlying secret data – e.g. if the item
stored db passwords, you’ll need to change the db password.
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.
Encrypted data bags in general do not have to use that file and
different items can use different shared secrets. For chef vault, only
those items that the node had access to will be 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.
I see where you’re coming from, but I disagree a bit. Protecting secrets
stored in the Chef Server has value. Even without something like chef
vault, it is possible to use different secrets for different items and
thus limit the impact of an attack.
Seth Falcon | Development Lead | Opscode | @sfalcon