[chef-dev] Re: Re: Re: Open source Chef Server API: big changes in internal code is coming ?

[Noah Kantrowitz < >]

On May 15, 2012, at 10:39 PM, Christophe L wrote:

> Hello,
> 
> We are trying to add a security layer between the client and the server.
> 
> For the moment, the rule is simple: a non-admin client is allowed to see 
> only the information related to it-self.
> 
> The rules will be as follows:
> 1) the endpoints /clients , /cookbooks , /nodes , /roles , /environments , 
> /search, /cookbooks/COOKBOOK_NAME on GET method will be forbidden for all 
> non-admin client, so they can't retrieve information about the whole 
> infrastructure and settings related to other servers
> 
> 2) the endpoints /clients/CLIENT_NAME, /nodes/NODE_NAME and 
> /nodes/NODE_NAME/cookbooks on GET method will be allowed only if 
> CLIENT_NAME and NODE_NAME match the UserId found in the HTTP header
> 
> 3) the endpoints /roles/ROLE_NAME, /environments/ENVIRONMENT_NAME and 
> /cookbooks/COOKBOOK_NAME/COOKBOOK_VERSION will be allowed only if the node 
> (defined by the userId in the HTTP header) is respectively assigned to the 
> role ROLE_NAME, in the environement ENVIRONMENT_NAME and has the cookbook  
> COOKBOOK_NAME/COOKBOOK_VERSION in its cookbook list.
> Those information will be retrieved using knife.
> 
> For the moment, we are thinking to go with an Apache Handler written in 
> Perl and doing some regulare expression on URL based on the UserId 
> available in the HTTP Header and some system calls to knife when extra 
> information are necessary.
> The Apache handler refusing to process the HTTP Request when the security 
> rule are not respected.
> This should work since in our infrastructure the Chef API is accessible to 
> a VHost proxy on Apache.
> 
> Could you please let us know your feelings / your advices about this 
> solution ?
> 
> Another question would be: will there be an ACL system (even a simple one) 
> in the new backend implementation ?

I've answered similar questions on here before so I'll keep this brief. 
Security isolation and/or multitenancy isn't something that can be 
retrofitted on to the open source codebase unless you want to effectively 
rewrite it. Yes, this is subpar and we would like to see it changed, but 
currently our (opscode's) backend dev cycles are being directed at getting 
Erchef up to snuff instead of improving the Ruby implementation massively. If 
this is truly a business requirement for you, Private Chef is a multitenant 
Chef server you can run on your own hardware. Beyond that the only way to get 
multiple effective chef servers is to run multiple chef-server-api daemons 
(and webui, expander). You can at least share some backend components, but 
the unit of security isolation in the open source codebase for now is the 
server instance. If you don't mind starting from scratch but aren't big on 
Ruby, you could take my Commis project (github.com/coderanger/commis) and gut 
a lot of implementation and/or add lots of ACLs and security checks. Hope 
this helps.

--Noah Kantrowitz

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail