Drive it off an attribute or data bag and give them the ability to manipulate that. You can do that via letting them update the data bag in the UI or via knife, or you can write a utility that lets them update it with ACLs that you establish in the utility.
Minimum Viable Product for that last thing would be a command line tool that runs setuid or setgid to some user which has read access to a chef user credential on disk (mode 400 or 440 so users can't read it without the utility) and then updates the data bag for the user. Then users could run that from the command line, and it could only allow updating that data bag and could do additional sanity checking, validation, authorization, audit logging, e-mail alerts, etc before doing the data bag upload. Obviously taint check your inputs since it would need to run with elevated privs. Or you could get crazy and write a web app in an MVC framework and just have data models that map onto data bags in Chef.
I'd start with the Chef ACLs around data bags in the UI/knife first and see if that worked for you though.
On Thu Sep 18 12:27:07 2014, Tiago Cruz wrote:
Hello,
I would like to know about best practices about how to deploy internal
applications using Chef to control the versions.
I used before with the the versions as attribute inside some roles or
recipe, but we need some sysadmin to do the deploy.
Now, I would like to give to the developers the option to do the
deploy by themselves without need to give them write permission on
chef-repo.
Thanks
--
-- Tiago Cruz
Archive powered by MHonArc 2.6.16.