[chef] Re: Re: Re: Re: Restrict access to nodes

[Jerry Raj < >]

Ah, I see. I was using open-source Chef, so I obviously could not see a 
way to make it work the way I needed.

Thanks for clearing that up.
-Jerry

On 27/05/14 4:29 pm, Noah Kantrowitz wrote:
> In open-source Chef yes, read access is global, but only admin keys can 
> create/update/delete. In enterprise Chef this is the default, but it can be 
> customized through the ACL system.
>
> --Noah
>
> On May 27, 2014, at 3:34 AM, Jerry Raj 
> <
>  >
>  wrote:
>
> > Thanks.
> > The way I understand it, the key identifies a user. The run-lists are 
> > associated with a node. So the user can assert any node name and run the 
> > run-lists associated with that node name. Or am I mixing things up?
> >
> > -Jerry
> >
> > On 27/05/14 3:50 pm, Noah Kantrowitz wrote:
> > > Access to the private key is considered authentication. The only way you know 
> > > which node is talking to the API is which key it uses. It is up to you to 
> > > ensure these are kept safe, though the default key generation system using 
> > > the validation key will write it out securely.
> > >
> > > --Noah
> > >
> > > On May 27, 2014, at 1:19 AM, Jerry Raj 
> > > <
> > >  >
> > >  wrote:
> > >
> > > > Hi,
> > > > I've been wading through the tutorials and almost everything works just fine. 
> > > > I had a question about how security works:
> > > >
> > > > As far as I can tell, once a client is created from the web-UI and its 
> > > > private key generated, a client can connect as any node using the private 
> > > > key. Is it possible to restrict a client to using just a subset of nodes? I'm 
> > > > thinking of a scenario where we want to make sure that the nodes only have 
> > > > access to the runlists configured for them.
> > > >
> > > > Thanks
> > > > -Jerry