Unable to create a chef vault secret from a recipe

[chirag-jog]

Hello,
I am trying to run create a chef vault secret from a recipe. I get a permission denied. I have tried different things including giving specific update permissions to the node/client on that specific databag but to no avail.

Here is the complete stacktrace and error: https://gist.github.com/chirag-jog/1aebe628bd6ddcf1c91c

[pelletiermaxime]

Just tried chef-vault for the first time and had the same problem when trying to create a secret from a recipe. Turns out my error was that my client doesn't have the permission to read the user I passed as an argument to 'admins'. I had luck when I set as admin the name of client where the recipe ran, but that's really not practical.

[benjaminmicucci]

@pelletiermaxime We tried doing that, however it did not work. We still received the 403.

[pelletiermaxime]

The same 403 ?
Another thing I had to do is to manually create the databag and add the "Update" permissions for the clients.

[benjaminmicucci]

Actually, we just got it work. I was looking at the wrong properties. Thanks! Is there any way to do this programmatically? I have a lot of nodes & will be constantly spinning up new ones. It seems tedious to have to either make individual knife calls or do it all via the UI. Thanks again!

[jcarapet]

I am running into the same issue on this as well. I am trying what I think is the suggested solution, but am not having a lot of work in making this work. I am sure I will figure it out.

Would it be within the scope of the cookbook to provide suggested solutions in the README, or at least link to some docs that describe it? That would probably help a lot of us newbies.

[hh]

Looks related to reading user public keys on hosted chef, need to figure out how to let a non-admin client(node) read them:

Chef::ServerAPI.new(....).get("users/#{name}") => 403 forbidden

Here is a pry-byebug / debug where I think we are getting the error:

From: /opt/chef/embedded/lib/ruby/gems/2.1.0/gems/chef-vault-2.6.1/lib/chef-vault/item.rb @ line 376 ChefVault::Item#load_admin:

    374: def load_admin(admin)
    375:   begin
 => 376:     admin = ChefVault::ChefPatch::User.load(admin)
    377:   rescue Net::HTTPServerException => http_error
    378:     if http_error.response.code == "404"
    379:       begin
    380:         $stdout.puts "WARNING: #{admin} not found in users, trying clients."
    381:         admin = load_client(admin)
    382:       rescue ChefVault::Exceptions::ClientNotFound
    383:         raise ChefVault::Exceptions::AdminNotFound,
    384:           "FATAL: Could not find #{admin} in users or clients!"
    385:       end
    386:     else
    387:       raise http_error
    388:     end
    389:   end
    390: 
    391:   admin
    392: end

[2] pry(#<ChefVault::Item>)> ChefVault::ChefPatch::User.load(admin)
Net::HTTPServerException: 403 "Forbidden"
from /opt/chef/embedded/lib/ruby/2.1.0/net/http/response.rb:119:in `error!'

[3] pry(#<ChefVault::Item>)> step

From: /opt/chef/embedded/lib/ruby/gems/2.1.0/gems/chef-12.6.0/lib/chef/user.rb @ line 179 Chef::User.load:

    178: def self.load(name)
 => 179:   response =  Chef::ServerAPI.new(Chef::Config[:chef_server_url], {:api_version => "0"}).get("users/#{name}")
    180:   Chef::User.from_hash(response)
    181: end

[hh]

I may be mistaken, but I think it is currently impossible to use hosted chef users as administratiors for a chef-vault encrypted data bag. How would one specify that a node/client has access to read a hosted chef users data at ChefVault::ChefPatch::User.load(admin) which ends up calling Chef::ServerAPI#get("users/#{name}") in chef-12.6.0/lib/chef/user.rb @ line 179

[hh]

@coderanger suggests using knife-acl to grant read access to the users container, but warns that using search to choose nodes to ecrypt to isn't very safe, because a node can claim to be in any role. The search results are, in a way, advisory only.

[jcarapet]

@hh , I should have followed up on this. I tried the knife-acl piece to some success, but once I ran it by security team to write from a node, they axed that idea immediately. It is no longer an issue. Thank you for the follow up on this.

[hh]

@jcarapet I don't think it matters whether you use knife-vault or run this on a node, the security issue seems to deal with the search results for the nodes not being reliable. I think it might be interesting to get a list of nodes from another source, and use name:X OR name:Y OR name:Z as the search field. I don't think that attribute can be overridden maliciously.