{"action":"created","issue":{"url":"https://api.github.com/repos/Nordstrom/chef-vault/issues/150","labels_url":"https://api.github.com/repos/Nordstrom/chef-vault/issues/150/labels{/name}","comments_url":"https://api.github.com/repos/Nordstrom/chef-vault/issues/150/comments","events_url":"https://api.github.com/repos/Nordstrom/chef-vault/issues/150/events","html_url":"https://github.com/Nordstrom/chef-vault/issues/150","id":68159263,"number":150,"title":"Allow clients (without a node) to be returned via searches.","user":{"login":"dblessing","id":2394772,"avatar_url":"https://avatars.githubusercontent.com/u/2394772?v=3","gravatar_id":"","url":"https://api.github.com/users/dblessing","html_url":"https://github.com/dblessing","followers_url":"https://api.github.com/users/dblessing/followers","following_url":"https://api.github.com/users/dblessing/following{/other_user}","gists_url":"https://api.github.com/users/dblessing/gists{/gist_id}","starred_url":"https://api.github.com/users/dblessing/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dblessing/subscriptions","organizations_url":"https://api.github.com/users/dblessing/orgs","repos_url":"https://api.github.com/users/dblessing/repos","events_url":"https://api.github.com/users/dblessing/events{/privacy}","received_events_url":"https://api.github.com/users/dblessing/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2015-04-13T18:10:53Z","updated_at":"2015-05-05T18:06:49Z","closed_at":null,"body":"We would like the ability to use a Chef client key to use in certain circumstances where it isn't feasible to refresh a vault each time a new node is added. For example, this could be used with AWS to drop a client key in an S3 bucket (protected via IAM roles) that would allow the EC2 instances to pull the encryption key from the bucket and decrypt a vault. However, since it's still a vault and not an encrypted data bag there can still be other nodes/clients and admins on the vault. It's much more flexible than a simple encrypted data bag.\r\n\r\nThis would probably be a simple implementation - allow the search query to return the client index, too, or provide another query flag to enable searching client index. "},"comment":{"url":"https://api.github.com/repos/Nordstrom/chef-vault/issues/comments/99161580","html_url":"https://github.com/Nordstrom/chef-vault/issues/150#issuecomment-99161580","issue_url":"https://api.github.com/repos/Nordstrom/chef-vault/issues/150","id":99161580,"user":{"login":"jf647","id":41579,"avatar_url":"https://avatars.githubusercontent.com/u/41579?v=3","gravatar_id":"","url":"https://api.github.com/users/jf647","html_url":"https://github.com/jf647","followers_url":"https://api.github.com/users/jf647/followers","following_url":"https://api.github.com/users/jf647/following{/other_user}","gists_url":"https://api.github.com/users/jf647/gists{/gist_id}","starred_url":"https://api.github.com/users/jf647/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jf647/subscriptions","organizations_url":"https://api.github.com/users/jf647/orgs","repos_url":"https://api.github.com/users/jf647/repos","events_url":"https://api.github.com/users/jf647/events{/privacy}","received_events_url":"https://api.github.com/users/jf647/received_events","type":"User","site_admin":false},"created_at":"2015-05-05T18:06:49Z","updated_at":"2015-05-05T18:06:49Z","body":"I think I've got a way to implement this without a breaking change, though it wouldn't involve changing the search query.  We already try to load admins as nodes first and clients second, so I think you can just pass your special client name as an admin.\r\n\r\nCalling them admins is a bit of a misnomer - they should perhaps be called 'api users'.  Nominally an admin also has permissions to read the public key of other clients and api users and to write to the data bag, but from a chef-vault perspective they're identical.\r\n\r\nChanging how the search query works would be a big change because now we'd have to store both queries in the keys bag, add another command line switch, process both queries on vault refresh, etc.\r\n\r\nSo, my idea is to add an optional third hash arg to ChefVault::Item::load and ChefVault::Item.new that lets you override the node name from the default of `Chef::Config[:node_name]` and the client key path from the default of `Chef::Config[:node_name]`.\r\n\r\nI think that will work, though I won't know for sure until I get into implementation.\r\n"}}