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

[Christophe L < >]

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 ?

Best regards,
Christophe

On Mon, May 14, 2012 at 8:14 PM, Daniel DeLeo < " target="_blank"> > wrote:

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

> Hello,
>
> Thanks for your answer.
>
> So as far as I understand, if we modify the source code of the REST API or implementing a Rack middleware, we will have to rewrite everything in some times, but if we work at the HTTP/REST/JSON level, the new implementation should stay compatible with our work.
> is my understanding correct please ?
>
> in how much time approximatively the shift to the new backend implementation is planned to be released please ?
>
> Our goal is to "place" some custom code between the client and the server. We were going to work at two level:
> - modifying the source code of the REST API
> - intercepting the HTTP request to the REST API in a Rack Middleware
>
> What would be the best way to achieve that in a way that our code won't need to be changed when the new backend implementation will be release please ?
>
> Thanks in advance for your feedback.
>
> Best regards,
> Christophe

What are you guys trying to do? There may be a variety of ways to achieve it.


--
Dan DeLeo