search

sspinc / terraform-provider-credstash

Terraform provider for secrets stored with credstash
MIT License
68 stars 35 forks source link

Accessing credstash table in another account #3

Closed james-gonzalez closed 7 years ago

james-gonzalez commented 7 years ago

Hi, first of all I'd like to thank you for putting this project together. If I can get it to work, it's really going to solve a fairly serious problem for me, which is storing passwords in plain-text.

Unfortunately, I can't get it to work in it's current state because I access my credstash(dynamodb) table like so:

credstash -t credential-store-dev -n arn:aws:iam::XXXX:role/credential-store-dev get database_password

To give you more information, we have an account, where the credstash dynamodb tables sit, and we use STS to assume role on this account, from our dev/staging/production accounts. For credstash, you just need to use the -n option so you can provide the ARN (which gives you the full path/including account number)

Is this possible to fix OR is there some way to get this working?

Thanks so much in advance!

tmichel commented 7 years ago

This is currently not supported. AWS credentials and session handling are kept to the minimum.

It would be pretty trivial to add this. Actually the credstash package can work with a provided AWSSession. If you want to take a crack at this please go ahead.

james-gonzalez commented 7 years ago

@tmichel thanks for the response. Understood, yes I can see that it's not supported. I've already got credstash implemented for managing other secrets, it just would be nice to have it manage terraform secrets in the same way. My solution is going to be to simply create new credstash dynamodb table per each AWS account. Kind of messy, but it will have to do for now!

tmichel commented 7 years ago

@cultavix We have a single AWS account but we do separate environments in separate VPCs and every environment has it's own credstash dynamodb table. I really like this setup because it isolates the secrets from each other. Limits exposure and also gives easier access control with IAM roles.