Does chef-vault require that a chef solo node be on a chef server? about chef-vault HOT 26 CLOSED

I also don't understand how it should work with Chef Solo.

from chef-vault.

I'm also having trouble understanding how the solo mode is supposed to work. Would it be possible to add a section to the README about it?

from chef-vault.

same issue here.

as it stands, chef-vault does not work with a chef-server-less approach since a ChefVault::Item appears to be bound to search and admin parameters. if those are empty, chef-vault throws up.

with a few modifications i got around that limitation for knife encrypt create. no idea about decrypt, yet.

from chef-vault.

You are correct in that a chef server is required to create the data bags. This is because chef-vault is using the chef server as the public key repository for encryption. Without that it has no place to go get public keys that correspond to a private key to use as an encryption point.

Also, in most chef-solo implementations there is not a chef private key on the server, because there is no communication that is being authenticated/authorized back to the chef server so most folks forgo the certificate. This makes using chef-vault impossible since it solely relies on a public/private key pair.

There are two use cases that I see for solo mode and different approaches to solve it.

1. Chef-solo for use in Vagrant (This is our main chef-solo use case)
2. Chef-solo for end server convergence (We don't do this, but have some ideas here)

Chef-solo for use in Vagrant

The way we make chef-vault work in this case, so that we can test/develop locally without the requirement for being online and connected to the chef server is to use our user/client pem to run the vagrant provision in the context of us. Here's how to do that.

1. Create your vault items for you as the admin
2. Modify your Vagrantfile to mount up your ~/.chef directory into the /etc/chef directory on the vagrant box
   config.vm.share_folder 'v-chef-client', '/etc/chef', "/Users/#{user}/.chef/client"
3. Set the vagrant box to run as you
   chef.node_name = user
4. Make sure to set the data_bag_paths for the provision
   chef.data_bags_path = 'some_path'
5. Make sure that your vault item json files are in the data_bags_path/vault directory

Now when vagrant does a provision using chef-solo it will run in the context of you and decrypt using your user pem.

Chef-solo for end server convergence

Basically the issue you need to solve here is key management. You have to securely distribute the private keys to your nodes and have a repository that stores the public keys for chef-vault to use. Currently the only key distribution mechanism that chef-vault supports is the chef-server. This is where, however, I think maybe chef-zero with security turned on may be able to help you. You could script out creating a node in chef-zero and taking the returned private key and distributing to the node. Then you could just point chef-vault at the running chef-zero instance to create the data bag files.

Your chef solo configuration would then need to include the data_bags_path directive and the *.json files would need to get distributed to the node as well.

I see this as pretty large overhead to use chef-vault for chef-solo.

If you have some other PKI infrastructure that you already use, then I would be interested in chatting about what that is and seeing if there is a plugin we could write for chef-vault that could use that PKI instead of chef server. Basic requirement is that you need to have the private key distributed to the end node securely and a repository somewhere of the public nodes that can be queried.

Other thoughts

I think some of the confusion probably comes from the mode names of 'solo' and 'client'. In retrospect I should not have called the modes that for this very reason. Really solo mode is about reading and writing the data bags from json files on disk and is intended for use in a CD/CI world where you keep your data bags in source control and sent through some sort of pipeline so you don't want to modify them directly on the chef server. It still expects that the converging nodes are running in a client configuration.

Client mode is really just chef-vault interacting with the chef server directly to read/write the data bags.

There are really two "functions" of chef-vault, one being the admin'ing of vault items and one being the nodes consuming vault items. The "mode" of the knife commands is focused solely on the admin'ing side of things and not on the consumption side.

I hope this helps clears up some confusion? Or perhaps makes it more confusing...

from chef-vault.

thanks. you just confirmed my fears.
we're pretty much out of luck it seems.

i do not have or want a central chef server. a vagrant-only solution doesn't really solve anything for me because, in the end, i'll need to solo-provision a real server.

in my ideal world chef-vault would upload my local secret key to the node i'm currently cooking and delete it afterwards. (for that reason it'd need to be decoupled from the node_name in knife.rb).
this way, key management will be left for me which i'll be comfortable with since at least i have the encrypted data bags in my repository and the problem of solo-distributing ssl certs to nodes solved.

from chef-vault.

Thanks for clarification.

When I tried to explore the solo variant, I had dumping JSON files in mind. I'd really like to store them in version control.

Still, I'm wondering, why solo is the default for --mode - feels like it is more an edge case.

from chef-vault.

I was playing around with this and using 'chef-client' in local mode will work (Chef 11.8). Support for this is added to Vagrant as a pull request ( hashicorp/vagrant#2496 ), which is not merged yet.

The only issue I had was with the berkshelf integration (because of berkshelf and vagrant-berkshelf). But that may work for you, glaszig, depending on how you can get the client private key to the node you are cooking.

from chef-vault.

or you can use chef-zero in the meantime until the ecosystem starts to catch up. here's the vagrant-chef-zero plugin

from chef-vault.

What about adding gpg support for public/private pairs using https://github.com/ueno/ruby-gpgme? This would potentially address key distribution for the "Chef-solo for end server convergence" use case, as well as add flexibility for chef-server or vagrant use cases. If I had the option, I would opt to target users by GPG key, as opposed to admin keys on the server.

from chef-vault.

Actually the ideal solution would be to have a plugin for vagrant or similar that embraces how vagrant works (one key for SSH for example) insecure key etc. Be able to do something similar that we can make the data bag items and allow the 'insecure chef client node key' to be used for decryption. it doesn't fully address all issues but it would be a good start.

from chef-vault.

I've been using encrypted data_bags exclusively for this purpose because they are already supported for chef_solo.

from chef-vault.

Though I'd love to see a solution that emulates the search/role-based decryption functionality baked in to chef-vault/chef-solo/vagrant (wherever it best belongs), @moserke's Chef-solo for use in Vagrant workaround works well for my current usecase.

from chef-vault.

@moserke - I am trying to use what you wrote above about Chef-solo for use in Vagrant with test kitchen and am close I think but still getting error that the vault item is not encrypted with my public key. So far I have:

1. The data bag that contains vault and vault_keys extracted as ./data_bags/[data_bag_name]/vault.json and ./data_bags/[data_bag_name]/vault_keys.json
2. My user is an admin of the vault item.
3. The ~/.chef folder that has my [user].pem in it mounted as /etc/chef on the vagrant box.
4. The following in my .kitchen.yml

driver:
box: rhel65-x86-64
box_url: http://.../rhel65-x86-64.box
synced_folders:
- ["/Users/<%= ENV['USER'] %>/.chef", "/etc/chef"]

provisioner:
name: chef_solo
data_bags_path: "./data_bags"
node_name: "<%= ENV['USER'] %>"

Am I setting the node_name in the wrong place? What am I missing?

Also if configured correctly would this work with chef-zero provisioner with test-kitchen also?

Thanks.

from chef-vault.

@daxgames Copy [user].pem to client.pem, chef is looking for /etc/chef/client.pem for the key by default.

As to chef-zero, I have not done a tone of playing with that, but I suspect, as long as the vault & vault_keys data bag items get pre-loaded into chef-zero, this should work fine.

from chef-vault.

@moserke - tried that too but forgot to include it in my last post. still getting the error.

from chef-vault.

@moserke - Does the folder that is mounted to /etc/chef need any other files like client.rb?

from chef-vault.

@SimonKaluza - Looks like you got chef-vault to work with solo. Can you provide examples of .kitchen.yml and/or Vagrantfile and any other relevant tips of a working config

from chef-vault.

Can you put the error message here? Maybe the output of the vagrant provision run?

from chef-vault.

@daxgames The setup I got working sounds basically similar the one you described above, though I'm not using kitchen for my testing so it's not a 1-to-1 comparison. When I tried this set it up, I used client.pem, but this didn't work as it seems chef-solo looks for a .pem file in /etc/chef that's named the same the node_name... Here are the relevant lines of my Vagrantfile:

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  #... Other Vagrant settings
  config.vm.provision :chef_solo do |chef|
      chef.data_bags_path = "~/data_bags"
      chef.roles_path = "roles" #probably not required for your purposes
      chef.add_role("my_role") #probably not required for your purposes
      chef.node_name = '#{pem_file_name_without_dot_pem}'
    end

  config.vm.synced_folder './synced_chef_folder', '/etc/chef', type: 'rsync'
# ... More Vagrant settins here
end

I've also created a synced_chef_folder instead of using the whole /Users/<%= ENV['USER'] %>/.chef" and have a symbolic link to my .pem file so I didn't have to pass in my entire local Chef config and potentially have Vagrant and/or Chef overwrite my local machine's Chef config during their its provisioning.

from chef-vault.

@moserke and @SimonKaluza

I figured out how to make chef-vault work with test-kitchen and chef-zero.

The settings in the .kitchen.yml below mounts ~/.chef as /etc/chef on the vagrant node, uses the chef-zero provisioner to upload the downloaded vaulted data bag items to the chef-zero server on the vagrant node, set the chef.node_name to ENV["chef_server_id"] and uses my ENV["chef server id"].pem to decrypt the vault items.

The only thing I had to do since my Chef server id is different from my Mac username is add export chef_server_id=xxxxx to my profile.

.kitchen.yml

driver_plugin: vagrant
platforms:
- name: rhel65-x86-64
  driver:
    box: rhel65-x86-64
    box_url: http://.../rhel65-x86-64.box
    http_proxy: <%= ENV['http_proxy'] %>
    https_proxy: <%= ENV['https_proxy'] %>
    synced_folders:
      - ["/Users/<%= ENV['USER'] %>/.chef", "/etc/chef", "disabled:false"]

provisioner:
  name: chef_zero
  data_bags_path: "./data_bags"
  client_rb:
    node_name: "<%= ENV['chef_server_id'] %>"                  # Add export chef_server_id=[your chef server id] to your ~/.bash_profile or ~/.zsh.after/envars.zsh
    client_key: "/etc/chef/<%= ENV['chef_server_id'] %>.pem"   # Add export chef_server_id=[your chef_server id] to your ~/.bash_profile or ~/.zsh.after/envars.zsh

suites:
- name: rhel
  run_list:
  - recipe[xxx]
  attributes:
    chef_client:
      config:
        log_level: ":debug"

./data_bags/[data bag name] contents

vault.json
vault_keys.json

from chef-vault.

@SimonKaluza thanks for the example, this got a chef-solo configuration working for me!

For some reason I received a No such file or directory - /etc/chef/client.pem error, but when I copied my #{username}.pem over to client.pem everything worked.

from chef-vault.

ty @daxgames , I will try your method. I'm new and I found this from Google. It does seem like chef-zero is the right way to go as chef-solo will be deprecated at some point per; https://www.chef.io/blog/2014/06/24/from-solo-to-zero-migrating-to-chef-client-local-mode/
AnneTheAgile

from chef-vault.

@daxgames
thanks for your solution, now I get OpenSSL::PKey::RSAError

padding check failed
Got to figure the issue

from chef-vault.

I've actually got a pattern for using chef-vault with Test Kitchen, and next week I hope to have a gem and a cookbook released that makes it super easy to do this. For now, you might want to look at my dissertation in this TK issue:

test-kitchen/test-kitchen#602

What I do today is create a fixture cookbook that programmatically creates a vault item, encrypted for all nodes (which in TK is just the node under test). That goes before my cookbook under test in the runlist (via .kitchen.yml), so the fixture cookbook creates the secret and the real cookbook uses the secret.

The TK issue linked above creates a problem where if the converge step fails, you can't converge a second time. The solution is to nuke the TK chef-repo using kitchen exec -c 'sudo rm -rf /tmp/kitchen', which will result in the node re-registering and creating a new keypair and vault on the next converge.

Look for more info about the gem and cookbook soon.

from chef-vault.

As to this thread itself, are there any specific issues with solo mode that are not working with v2.4.0? This issue has been open way too long and if there are failing scenarios, I'd like to at least get the Aruba suite extended to cover them, even if we can't fix them immediately.

from chef-vault.

Closing for lack of further feedback.

from chef-vault.