4 ms·

Terraform seems like a great project, and the new import feature could nearly convince me to switch. My biggest barrier to using it is the lack of cross-account

Terraform seems like a great project, and the new import feature could nearly convince me to switch. My biggest barrier to using it is the lack of cross-account role support with AWS[0]. [0] https://github.com/aws/aws-sdk-go/issues/472 https://github.com/aws/aws-sdk-go/issues/472

dfinninger 10y ago
That was a pretty big issue for us as well. We've gone through some acquisitions and we left with a bundle of different accounts. Wound up taking a day and writing a ruby script that checked out an STS token, and exec'ed a new bash shell with the correct environment variables. the $PS1 has the account name in there so it's not too hard to know what shell points where. Also helpful that we set up a "control account" that handles consolidated billing and user login. We've had some pretty good success so far, however I can definitely see how that feature would be good baked-in somehow.
- Rapzid 10y ago
  Holy cow, I did the exact same thing with the bash shell and the custom $PS1. That's crazy. The main difference is I just piggy backed off "aws s3 ls" and let it handle prompting for the MFA token and getting the temporary credentials.
- JimmyL 10y ago
  We use https://github.com/atward/aws-profile/blob/master/aws-profile https://github.com/atward/aws-profile/blob/master/aws-profil... to do pretty much the same thing, although without the $PS1 hacking. Our rule is that a user's default profile should always be the "control account" (on which they have permission to do nothing except STS and AssumeRole), and that they need to use this wrapper and explicitly specify a profile for all "real" API commands. This also works nicely with MFA. Having this built into TF would be nice, but there are enough tools out there that don't support AWS role-jumping that I suspect we'll end up using that wrapper for a long time.
- micah_chatt 10y ago
  Success! The issue was just merged[0], hopefully this will make its way into TF soon. [0] https://github.com/aws/aws-sdk-go/issues/472#issuecomment-237342876 https://github.com/aws/aws-sdk-go/issues/472#issuecomment-23...

dfinninger 10y ago

That was a pretty big issue for us as well. We've gone through some acquisitions and we left with a bundle of different accounts. Wound up taking a day and writing a ruby script that checked out an STS token, and exec'ed a new bash shell with the correct environment variables. the $PS1 has the account name in there so it's not too hard to know what shell points where. Also helpful that we set up a "control account" that handles consolidated billing and user login. We've had some pretty good success so far, however I can definitely see how that feature would be good baked-in somehow.

Rapzid 10y ago
Holy cow, I did the exact same thing with the bash shell and the custom $PS1. That's crazy. The main difference is I just piggy backed off "aws s3 ls" and let it handle prompting for the MFA token and getting the temporary credentials.
JimmyL 10y ago
We use https://github.com/atward/aws-profile/blob/master/aws-profile https://github.com/atward/aws-profile/blob/master/aws-profil... to do pretty much the same thing, although without the $PS1 hacking. Our rule is that a user's default profile should always be the "control account" (on which they have permission to do nothing except STS and AssumeRole), and that they need to use this wrapper and explicitly specify a profile for all "real" API commands. This also works nicely with MFA. Having this built into TF would be nice, but there are enough tools out there that don't support AWS role-jumping that I suspect we'll end up using that wrapper for a long time.
micah_chatt 10y ago
Success! The issue was just merged[0], hopefully this will make its way into TF soon. [0] https://github.com/aws/aws-sdk-go/issues/472#issuecomment-237342876 https://github.com/aws/aws-sdk-go/issues/472#issuecomment-23...