Comment by eropple | Hacker News Reader

Comment by eropple | Hacker News Reader

So this is a neat idea, because Credstash and Sneaker are certainly not perfect gizmos, but it leads to the turtles problem: how do I securely handle the initial key that's being plopped on systems? If I can do that, I don't need Cryptic.

I've become a big fan of Credstash over the last few months largely because it solves (well, more like makes irrelevant, I wouldn't really strongly say it's "solved") this problem through using AWS as a trusted third party. Further, Credstash actually handles key ACLs in a much, much smarter way in that it uses KMS encryption contexts, which can be dropped into an IAM policy's Condition block, to further restrict access to secrets. Cryptic doesn't seem to offer this, and its use of Redis as a backing store (itself intended to be used in trusted environments) makes me worried, too.

If continuing along with this project--and please don't take this as discouraging, it seems largely reasonable as a thing!--I would look in more depth at how Credstash uses KMS and bloodily rip it off to improve Cryptic's KMS functionality; it's very, very good at what it's doing.

Credstash looks great, but having written something very similar for internal use (a secrets management system using KMS and S3 for use by EC2 instances) I was expecting it to have built in functionality to manage IAM policies the way you describe. Otherwise I'm not sure how this restricts different roles from accessing each other's secrets, which is the essential part of defense in depth for secret management.

For example, with S3, I have been defining IAM policies that restrict each role's access to just the secrets granted to that role, with a prefix-conditional IAM statement. You can further define similar parameterized policies for IAM users and groups without even enumerating their names.

As mentioned, KMS uses encryption contexts (a set of key-value pairs) to namespace your secrets. KMS won't decrypt the data key if you aren't in the key policy or your IAM policies don't allow access to that particular encryption context.

You're doing it at the S3 object level (presumably with a single KMS key?). Credstash does it at the KMS access level. Both are roughly equivalent, but Dynamo accesses are a lot cheaper in my neck of the woods than S3 accesses.

It seems to me that cost is negligible for any of the use cases. The KMS CMK cost will dominate access cost in my estimation. I see that Credstash cites latency as a factor in favor of S3, which is not a major factor if you retrieve a secret only once in a while and put it into memory, but could enable cool use cases where you really retrieve it on demand. S3 does have other advantages - ease of use and granularity of IAM access control, I think.

The Credstash documentation and code lead me to believe you are responsible for managing your own IAM policies - it won't set the policies in credential writer mode. Is that not correct? I expect this functionality to be part of the secret manager.

> I see that Credstash cites latency as a factor in favor of S3, which is not a major factor if you retrieve a secret only once in a while and put it into memory

Sorry, I wasn't clear. I meant "cheaper" in terms of time. I have a lot of machines in flight at any time, and I do actively roll credentials--chef-zero runs every five minutes and pulls credentials out of Credstash. S3 accesses add latency, which slows my converges (sometimes by a lot; I currently have around ~25 secret lookups in one particular Chef run).

> I expect this functionality to be part of the secret manager.

I'm not saying you're wrong to want that, but I'm very skeptical of it--extremely skeptical. I can't envision a situation where I'd rather have policy management as part of the secret manager as opposed to part of my provisioning infrastructure. My KMS accesses are in IAM roles; there is no situation in which I would ever want Credstash to manage those, because I have other stuff in them! I build my policies in CloudFormation, just like I do everything else.

If anything, my biggest criticism of Credstash is that it has a hardcoded table name that I'd rather was an environment variable so that I could establish that via CloudFormation and dump it into an env var via Chef.

In many cases, I think the secret manager should be part of your provisioning infrastructure. There are certainly other reasonable ways to structure this though - as long as you're clear on your threat model.

Would you agree that the secret manager should at least print out a suggested IAM policy for you to use? IAM policies are complex, tricky, and easy to mess up. I think it should absolutely be the job of the secret manager to at least sanity check your policies, if not write them directly.

> S3 accesses add latency [vs dynamodb], which slows my converges

That's useful to know, thanks.

I don't find IAM policies to be tricky, to be honest. It may just be familiarity; I have been doing this for a little bit of time now. I'm also not really sure what sort of interface for generating those policies without introducing to the secret manager its own notion of "policies"--at which point you're duplicating effort and work.

(I also wouldn't be able to use any policy spat out by the tool in the first place--I use a Cfer, Ruby DSL, to generate CloudFormation and all I'd be doing is transliterating it over.)

> I don't find IAM policies to be tricky, to be honest. It may just be familiarity; I have been doing this for a little bit of time now.

Then you are an elite AWS operator, but you also have to think about how to teach and review work from other, less skilled operators working with you. In my experience it's not easy at all to do that with something as critical as IAM, so when I'm orchestrating resources, I heavily rely on IAM policy automation and built-in sanity checks.

My policies are automated. I wrote the automation. :) And thank you for the compliment, but I wouldn't call myself "elite", merely "pretty good". Seriously, this is literally all it is:

   def kms_read_policy(contexts)
     contexts.map do |context|
       {
         PolicyName: "kms-read",
         PolicyDocument: {
           Version: '2012-10-17',
           Statement: [
             {
               Effect: 'Allow',
               Action: 'kms:Decrypt' ,
               Resource: [
                 Cfer.cfize('arn:aws:kms:C{AWS.region}:' \
                           'C{AWS.account_id}:key/C{Fn.ref(:CredstashKey)}')
               ],
               Condition: {
                 StringEquals: 
                   context.map do |k, v|
                     [ "kms:EncryptionContext:#{k}", v ]
                   end.to_h
               }
             }
           ]
         }
       }
     end.to_a
   end

And a single DynamoDB policy in a managed policy that allows for querying the `credential-store` table. This just is not rocket science. It's helped by cfer[0] and cfer-provisioning[1] being pretty great, but it's very achievable.

[0] - https://github.com/seanedwards/cfer

[1] - https://github.com/seanedwards/cfer-provisioning (I'm a maintainer)

I'm aware of the context parameter passed to KMS, and it is indeed something I plan on adding - one step at a time!

This was largely a side project that's gone quite well so far(!) - it's something I'll continue to add to. Any other suggestions are more than welcome.

Like it says in the readme, I just wanted a simple (single binary) deployment - it's in no way a dig at credstash.

I get you--I mean, if this was Credstash-compatible (using DynamoDB), I'd probably use it.

Reply on news.ycombinator.com