Knife Chef recipes as non-root user?

Chef Infra (archive)
1

As an application developer there is a real need to use Knife utility to execute Chef recipes ad-hoc,
i.e. some recipes are required to accomplish tasks that do not fall within the run_list for a node or group of nodes. There is also a very real need (mandatory) that application developers only have non-root access, i.e. run only with the permissions the user is given. I have found that by creating a new group, say ‘chef_app_dev’, and changing access permission for the chef-client on each node (’/etc/chef’ and ‘/opt/chef’ directories) I can then add the new ‘chef_app_dev’ group to the application developer user and execute Knife or run chef-client directly on a node with the correct non-root user permissions.

For example, instead of:

knife ssh node.fqdn.com 'sudo chef-client -o "recipe[msg_server::shut_down]"' -x app_dev_user -P 'xxx' --manual-list

I can now remove the ‘sudo’ arg and get permissions for ‘app_dev_user’:

knife ssh node.fqdn.com 'chef-client -o "recipe[msg_server::shut_down]"' -x app_dev_user -P 'xxx' --manual-list

Is this the only way (a good way) to accomplish my goal for using Knife as a non-root user?

I’m new to Chef, but it seems to me it is not designed well to separate the needs of SysAdmins vs. App Developers. Application developers should never be allowed to run as root - in fact our security won’t let us (and neither should yours). The Chef server allows for multi-tenancy through the use of Organizations, but does not allow for multiple clients with differing permissions on a node. This would get even more problematic if different application development teams had shared resources with different permissions and needed to use Chef, i.e. I don’t want another dev team touching my app.

BTW, I’m working on a distributed application with several Roles running on many nodes, so chef solo is not really a viable option as it would be difficult to maintain. I haven’t investigated this option yet, but I’m wondering if Docker containers would be a better answer to solve multi-tenancy issues? If anyone has used Docker with Chef in this way I’d be interested in how this was accomplished.

Any ideas, thoughts or suggestions would be appreciated. Thanks.

2

You can definitely run Chef like this but a lot of functionality will be missing. You’ll be unable to run any commands that require root, so things like the package resource are right out. You won’t be able to modify the user on execute resources or (mostly) file owners. Chef itself will work fine, but almost no community cookbooks will help you and a lot of the docs aren’t written for this case so just know that you’ll be on your own a little (though please do ask questions on here or in Slack as you have them).

As for Docker, there is no way to use Docker without root access or the equivalent and anyone that tells you different is either mistaken or is trying to sell you something.

3

Thanks for the input. Sounds like this is the correct path to take at this time. Things like package installs, etc. have to be requested and done by SysAdmins (by Chef or however they like), application developers only need to manage their own apps so their own permissions are all that will ever be needed. It still seems strange this isn’t handled within Chef itself by allowing setup of multiple clients on a node, the documentation for running as non-root doesn’t really provide what is necessary. Perhaps this feature should be requested - I’d be surprised if others would not find this useful.

4

The devops way to do this is for your sysadmins and developers to collaborate. You could set up a code review process where sysadmins review devs' Chef code, for example. You'd probably teach each other a lot, and devs would have more ownership over package installs and would be able to do stuff like modify sysctl settings to optimize applications, while still giving the systems folks insight and a level of control over what's going on.

5

Thanks for the suggestion. I’ll probably start this as another topic, but I want to have hooks in Git repository to spin up VMs to test cookbooks before they can be uploaded to the Chef server. As you suggest it would seem appropriate to have sysadmins review the cookbooks and upload them and not allow app developers to upload cookbooks at all since that would allow them root access through run_list - seems like Chef admins should be monitoring cookbooks or forcing ‘sudo to user’ for developer cookbooks. This appears to be a very awkward way to manage cookbooks for something that should be seamless and easy for developers and sysadmins alike.

6

This appears to be a very awkward way to manage cookbooks for something
that should be seamless and easy for developers and sysadmins alike.

Is it awkward because Chef or because of the way we think about security?
We often think about who has access to the box. Why? Security is really
about what happens on the box, and if I have a mechanism to ensure that bad
actors don't have the ability to put code/perform actions on my box, I can
treat my good actors (Sysadmins and Developers) the same.

You already mention the start of this, hooks in git that upon a change spin
up test instances to verify if things work. We can also extend that (and
our testing) to ensure that things Sysadmins care about (who's in the
sudoers file, if ssh is setup correctly, telnet isn't installed, etc).

This, combined with a code review process that includes contribution from
SysAdmins gives us good confidence about who pushed what code where and
when. And if things go wrong, we can figure out what happened, fix our
process and go again.