Re: some questions

[snacktime <snacktime@gmail.com>]

I think an rbac system would probably solve most of the problems and be more flexible.    

Something like this.

- Roles can be assigned to cookbooks and recipes.
- Clients are added to roles at the cookbook or recipe level.
-  Permissions are added to roles 

Roles can be inherited, so if you have a role on a cookbook, you automatically have that role on all it's recipes.  

Permissions might not be necessary, but they are a simple add on and allow a lot more customization at little expense.   

I wrote a rails plugin that does exactly the above a while back.   Would probably take a couple of nights hacking to get it working with couchdb given that I've never written a couchdb view and the main sql query is moderately complex.

On Wed, Apr 22, 2009 at 7:17 PM, David Lee <david.lee@kanji.com.au> wrote:

As a side note, there's no ORM for chef is there? IE, rather than being able to use something like ActiveRecord, the complexity Miguel is flagging must be dealt with directly via ferret searches(?)

I'd agree with Miguel that his approach makes sense to solve the security problem he raised; tags / roles / etc seems like a separate set of enhancements best considered afterwards, in the interests of improving security as quickly as possible.

just my 2c

- David

Miguel Cabeça wrote:

Hi,


On 2009/04/17, at 21:01, Adam Jacob wrote:

We've got some thoughts on how this might be accomplished, which I
just posted to the wiki at:

http://wiki.opscode.com/display/chef/Roles+and+Infrastructures

The gist is adding three new concepts:

1) Tags

2) Roles

3) Infrastructures

B) It would allow for automatic assignment of recipes based on policies.

I think there are four new concepts in this description, the fourth being the policy that was mentioned on B). As I told Adam on #chef, there are four new concepts to add to the existing Nodes, Cookbooks, Recipes, Definitions, Attributes, Libraries, Files, Templates, Resources, Providers and Search Indexes. It will steep even more the chef learning curve.

I think this is a bit of over-engeneering, at least to solve the original all-cookbooks-to-all-clients security problem I've mentioned. And it may not solve the problem completely. If the chef server unit of access control is the cookbook, it will be impossible to have sensitive data in one cookbook that has recipes for multiple types of servers. For example I have a postfix cookbook with postfix::sattelite, postfix::relay and postfix::store recipes, the postfix::relay serves remote files with sensitive data that the postfix::sattelite should not have acess to.

I have some (maybe uninformed) opinions on the new concepts introduced:

1) Tags : I don't see the diference of this and an attribute of the node named 'tags' that could be set automaticaly or manually in a recipe.

2) Roles: I've implemented this already as a toplevel cookbook with several recipes in it. Each node has  one or more of this recipes like for example role::mailstore, or role::ldapmaster or role::kerberoskdc. It's not dynamic, but is there a need for this to be dynamic?

3) I didn't understand the use for this concept. Doesn't this overlapp with roles? A 'testing' infrastructure should have nodes with 'testingX' roles

4) I didn't understand this policy concept either.

I'm afraid that the complexities involved in implementing all this features will postpone the resolution of the all-cookbooks-to-all-clients problem.

I was thinking of an approach based on scanning all recipes on chef server for include_recipes, remote_file and remote_directory resources. That would build an ACL that would allow only authorized nodes to acess the resources.

Best Regards

Miguel Cabeça

--

David Lee

Application Development Coordinator
Kanji Group Pty Ltd

02 8272 9483

david.lee@kanji.com.au

---
This message and any attachment are confidential and may be privileged or otherwise protected from disclosure.  If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system.  If you are not the intended recipient you must not copy this message or attachment or disclose the contents to any other person.

This email message does not constitute legal, financial or any other kind of advice and reliance must not be placed on its contents.  Any advice will be prefixed with a notice to that effect - and unless such a notice is affixed all liability for the contents of this email is disclaimed. The integrity of this email, its contents or any attachments is not certified in any way by the sender.

Liability limited by a scheme approved under Professional Standards Legislation