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

[Noah Kantrowitz < >]

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
>>

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