3 ms·

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

by ak217 10y ago

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.

eropple 10y ago
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.)
- ak217 10y ago
  > 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.
  - eropple 10y ago
    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 https://github.com/seanedwards/cfer [1] - https://github.com/seanedwards/cfer-provisioning https://github.com/seanedwards/cfer-provisioning (I'm a maintainer)

by ak217 10y ago

eropple 10y ago

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

ak217 10y ago
> 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.
- eropple 10y ago
  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 https://github.com/seanedwards/cfer [1] - https://github.com/seanedwards/cfer-provisioning https://github.com/seanedwards/cfer-provisioning (I'm a maintainer)