Encrypted Data Bags - Preemptive Key Retrieval

Chef Infra (archive)
1

Hello,

I’m using encrypted data bags in one of my cookbooks. I have the secret key
stored in another secure network location that nodes can access as needed.
I’d like to have the recipe retrieve the secret key, use it, and then
delete the key on the node when finished. I’m having trouble getting those
steps to happen in the proper order and while I understand why, I haven’t
been able to find a satisfactory solution. The point is to avoid letting
the key sit unused on the node.

When the server is first provisioned, I put a dummy key at
/etc/chef/encrypted_data_bagsecret so that load_secret doesn’t fail when
trying to find it. In my cookbook I have something like:

Bash “pull-key” do
code <<-EOH
Rename dummy key
Copy the real key from network location to local file system
EOH
end

key =
Chef::EncryptedDataBagItem.load_secret(“/etc/chef/encrypted_data_bag_secret”)
db_secrets = Chef::EncryptedDataBagItem.load(“passwords”, “database”, key)
db_pass = db_secrets[“db_pass”]

. . .

Bash “pull-key” do
code <<-EOH
Delete real key
Rename dummy back
EOH
end

The EncryptedDataBagItem.load line passes fine, but accessing the bag is
where I’m stuck. Chef wants to decrypt the bag with the real key and assign
the variable before the real key has even been copied to the node. I
thought about using another tool like Jenkins or something to first
initiate a copy of the key and then trigger chef-client, but that breaks my
automation process. Is it possible to somehow force the copy to happen
before data bag is accessed?

2

On Jan 23, 2015, at 12:19 PM, FusionX86 fusionx86@gmail.com wrote:

Hello,

I’m using encrypted data bags in one of my cookbooks. I have the secret key stored in another secure network location that nodes can access as needed. I’d like to have the recipe retrieve the secret key, use it, and then delete the key on the node when finished. I’m having trouble getting those steps to happen in the proper order and while I understand why, I haven’t been able to find a satisfactory solution. The point is to avoid letting the key sit unused on the node.

If you have a way to safely store and distribute the decryption key, why not just store the passwords in that too?

Your actual issue is that Chef is a two-pass system, first all recipes are compiled to resources, and then all resources are converged. That means that the code outside of resources happens before any resources execute. You'll want to switch the retrieval code to be in Ruby, and probably use a handler to do the delete just in case the run fails part way through.

--Noah