[chef] Re: Re: Fwd: Re: Re: AWS Security Groups

[Greg Zapp < >]

I use this on Windows to block access with exceptions for SYSTEM and Administrator(which may actually be redundant) in case anyone is interested: https://gist.github.com/ProTip/c80b1a3a29e488a6dd6d .

Linux has similar facilities for creating iptable rules based on user.

-Greg

On Wed, Nov 19, 2014 at 1:33 PM, Peter Burkholder < " target="_blank"> > wrote:

IAM roles are great, but beware that local users can use the instance metadata to authenticate to the same S3 buckets. You can mitigate that by using firewall rules to block local access to 169.254.169.254.

--Peter

On Tue, Nov 18, 2014 at 4:27 PM, George Miranda < " target="_blank"> > wrote:

Forwarded to the list, since it appears to have been only (mistakenly) addressed to me.

---------- Forwarded message ----------
From: Greg Zapp < " target="_blank"> >
Date: Mon, Nov 17, 2014 at 4:31 PM
Subject: Re: [chef] Re: Re: AWS Security Groups
To: " target="_blank">

Hi Douglas,

For what it's worth I use S3 to store extra IAM role secrets.  Each IAM role has access to an S3 object(or prefix) where extra secrets related to that role are stored in json files.  I fetch those down in a "secrets" cookbook that then loads them into the run.  Some cookbooks won't be flexible enough for this; they care too much about how the information gets into the Chef run.  In those cases I'll either work around it or fork the cookbook as necessary.  I try to create my own bottom level(infrastructure?) cookbooks/recipes/providers to not concern themselves with actually fetching the secrets from their source.   I use a cookbook that prevents certain node attributes from being saved back to the server "blacklist-node-attrs", this is configured to not save anything under the "secrets" key however I will probably investigate using chef.run_state.

I know this doesn't have anything to do with data bags, but maybe it will give you some ideas that will help you accomplish your goals.

Cheers,

   -Greg

On Tue, Nov 18, 2014 at 10:11 AM, George Miranda < " target="_blank"> > wrote:

Managing secrets is hard and Chef is not a magic pony.  "Infrastructure as Code" simply exposes a number of pain points felt by the security community for years and obscured by the fact that most people manually handle authentication with passphrases typed in or some sort of multi-factor method handled manually.

For more background on challenges/options, check out great coverage on this in a Foodfight favorite from last year:

http://foodfightshow.org/2013/07/secret-chef.html

On Mon, Nov 17, 2014 at 12:46 PM, Douglas Garstang < " target="_blank"> > wrote:

Seems like 'infrastructure as code' has a ways to go.

On Mon, Nov 17, 2014 at 12:44 PM, Eric Herot < " target="_blank"> > wrote:

Chef Vault does address one of the earlier concerns you raised about the scalability of mass-distributing keys to use for decrypting data bags.  Instead it uses the client keys on the individual nodes to encrypt separate copies of your data bag item (one for each host that’s allowed to access it).  That way you don’t have to worry (much) about key management, and access to the data is not universal (like it is with normal encrypted data bags, which were invented mainly as a way to not store sensitive data in source control).