One of our engineers wrote (and we subsequently open sourced [1]) a simple API endpoint for Berks 2x. This allows us to use an organization on our enterprise chef server - but give an API endpoint for the Berksfile to point to so that there is no need to give any engineers keys to the chef server.With Berks 3 - you will need to run an API [2] (or use api.berkshelf.com) anyway, so when berks 3.0 ships should be a minor change to your berksfile (if and when you do upgrade).On Mon, Jan 6, 2014 at 7:00 PM, Joe Nuspl < " target="_blank"> > wrote:
Since a chef-server can be a Berkshelf source, I'm wondering how people are dealing with client keys.
Our CI will take care of uploading cookbook so "developer" access will be read-only.
I see a couple ways to approach this:
1) One global client.pem that all developers will use. Since the endpoint is behind a VPN, if that key gets out, the exposure is mitigated.
2) Managing individual client per developer. Although this is the most "secure", it does carry the highest ongoing maintenance cost.
3) Disabling authentication all together (i.e. chef-zero)
4) Since I already have access to the developer's ssh public via LDAP, somehow tie them together.
What are others doing?
Joe
Archive powered by MHonArc 2.6.16.