[chef] Re: Chef deregistration via an external client

[John Keiser < >]

I'm not 100% clear on your use case, but if you:

1. Give dereg permissions to read and delete in the /containers/clients ACL (the 

2. Give dereg permissions to read and delete in each and every client under /clients/*

Doing #1 doesn't automatically get you #1.  If you need a tool to edit the acls, knife edit can probably help: knife edit acls/containers/clients and knife edit acls/clients/* will let you edit the individual permissions.

--John

On Mon, Feb 23, 2015 at 1:21 PM, Ed Ropple < " target="_blank"> > wrote:

Hi,

So I'm working on implementing a Chef deregistration mechanism for nodes/clients in AWS autoscaling groups. Because of the lack of guarantees around soft termination in AWS, I have an external node that's intended to handle ASG notifications (delivered via SNS to an SQS queue, it's nothing new).

The problem I'm running into is centered around authentication. In Chef Manage (currently using Hosted Chef), I've created a client 'dereg', arranged storage for its private key, so on and so forth. That's fine. I've since encountered an issue with Chef permissioning, in that it doesn't appear that I can say "this client is able to read and delete other clients"; I can manually grant permissions through Chef Manage for 'dereg' to be able to modify/delete other nodes and clients, but I can't seem to make this a blanket grant for that client. I can do that with a user, but for obvious reasons I neither want to go create another Hosted Chef account (and find an email address for it) nor increase my attack surface by enabling destructive access via a password-based account.

Any advice on implementing this sanely and securely?

Thanks,
Ed