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:
-
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.
-
Managing individual client per developer. Although this is the most “secure”, it does carry the highest ongoing maintenance cost.
-
Disabling authentication all together (i.e. chef-zero)
-
Since I already have access to the developer’s ssh public via LDAP, somehow tie them together.
What are others doing?
Joe
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).
[1] GitHub - dyninc/cookbookapi: Simulates the opscode community API by serving cookbooks from a chef server or private chef organisation
[2] GitHub - berkshelf/berkshelf-api: Berkshelf dependency API server
On Mon, Jan 6, 2014 at 7:00 PM, Joe Nuspl nuspl@nvwls.com 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:
-
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.
-
Managing individual client per developer. Although this is the most
"secure", it does carry the highest ongoing maintenance cost.
-
Disabling authentication all together (i.e. chef-zero)
-
Since I already have access to the developer's ssh public via LDAP,
somehow tie them together.
What are others doing?
Joe
Will the "Enterprise Chef" (https://manage.opscode.com) ever act as a
Berkshelf API source?
Ringo
On 7 January 2014 05:44, Pete Cheslock petecheslock@gmail.com wrote:
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).
[1] GitHub - dyninc/cookbookapi: Simulates the opscode community API by serving cookbooks from a chef server or private chef organisation
[2] GitHub - berkshelf/berkshelf-api: Berkshelf dependency API server
On Mon, Jan 6, 2014 at 7:00 PM, Joe Nuspl nuspl@nvwls.com 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:
-
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.
-
Managing individual client per developer. Although this is the most
"secure", it does carry the highest ongoing maintenance cost.
-
Disabling authentication all together (i.e. chef-zero)
-
Since I already have access to the developer's ssh public via LDAP,
somehow tie them together.
What are others doing?
Joe
Ringo,
It won't ever be part of the Management Console, because that's just the
web interface. There has been talk of making an endpoint in the Chef server
itself, but not any work currently in progress.
Supermarket https://supermarket.getchef.com/ will be implementing the
Berks /universe endpoint (see
https://github.com/opscode/supermarket/pull/431), and you can run your own
internal instance of Supermarket (this isn't super easy yet, but we will
have Omnibus packages for it at some point.)
Hope that's useful.
Thanks,
On Thu, Jun 19, 2014 at 9:16 AM, Ringo De Smet ringo.desmet@gmail.com
wrote:
Will the "Enterprise Chef" (https://manage.opscode.com) ever act as a
Berkshelf API source?
Ringo
On 7 January 2014 05:44, Pete Cheslock petecheslock@gmail.com wrote:
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).
[1] GitHub - dyninc/cookbookapi: Simulates the opscode community API by serving cookbooks from a chef server or private chef organisation
[2] GitHub - berkshelf/berkshelf-api: Berkshelf dependency API server
On Mon, Jan 6, 2014 at 7:00 PM, Joe Nuspl nuspl@nvwls.com 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:
-
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.
-
Managing individual client per developer. Although this is the most
"secure", it does carry the highest ongoing maintenance cost.
-
Disabling authentication all together (i.e. chef-zero)
-
Since I already have access to the developer's ssh public via LDAP,
somehow tie them together.
What are others doing?
Joe
--
Nathan L Smith
smith@getchef.com
without manipulating the original cookbook you can just execute an overwrite recipe afterwards. I'm sure there are slicker, more oop oriented ways to do it though.
This is a common problem in a lot of the community cookbooks though. Partially hard coded values in resources are the most difficult to work around without altering the original recipes.
Sent from my iPhone
On Jun 20, 2014, at 3:37 PM, Nathan L Smith smith@getchef.com wrote:
Ringo,
It won't ever be part of the Management Console, because that's just the web interface. There has been talk of making an endpoint in the Chef server itself, but not any work currently in progress.
Supermarket will be implementing the Berks /universe endpoint (see https://github.com/opscode/supermarket/pull/431), and you can run your own internal instance of Supermarket (this isn't super easy yet, but we will have Omnibus packages for it at some point.)
Hope that's useful.
Thanks,
On Thu, Jun 19, 2014 at 9:16 AM, Ringo De Smet ringo.desmet@gmail.com wrote:
Will the "Enterprise Chef" (https://manage.opscode.com) ever act as a Berkshelf API source?
Ringo
On 7 January 2014 05:44, Pete Cheslock petecheslock@gmail.com wrote:
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).
[1] GitHub - dyninc/cookbookapi: Simulates the opscode community API by serving cookbooks from a chef server or private chef organisation
[2] GitHub - berkshelf/berkshelf-api: Berkshelf dependency API server
On Mon, Jan 6, 2014 at 7:00 PM, Joe Nuspl nuspl@nvwls.com 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:
-
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.
-
Managing individual client per developer. Although this is the most "secure", it does carry the highest ongoing maintenance cost.
-
Disabling authentication all together (i.e. chef-zero)
-
Since I already have access to the developer's ssh public via LDAP, somehow tie them together.
What are others doing?
Joe
--
Nathan L Smith
smith@getchef.com