search

fpco / terraform-aws-foundation

Establish a solid Foundation on AWS with these modules for Terraform
MIT License
204 stars 98 forks source link

Documenting cross account modules usage #182

Open bugok opened 5 years ago

bugok commented 5 years ago

There are several modules which deal with defining AWS cross account resources:

It would be helpful to have documentation (and an example) of how to use those modules together. What plugins should be used in each account, and how.

Something like what's in: https://github.com/azavea/terraform-aws-cross-account-role.

I've been trying to define such cross account access, and it's unclear to me - but it may be my inexperience.

Thank you.

ketzacoatl commented 5 years ago

Hi @bugok, thanks for the issue. You are right that the IAM modules don't have enough documentation. In the meantime, this ought to help: https://github.com/fpco/terraform-aws-foundation/tree/master/modules/setup-meta-infrastructure

bugok commented 5 years ago

Not sure if I should open anther issue about this or not, so trying to reduce the noise by using this one:

Looking at the cross-account-group module, there's a reference to MFA. I don't see anything related specifically to MFA there, and I think that the mfa_policy_arn variable could be renamed to something like policy_arn, as any policy can be used.

Does this make sense? This would probably break existing usages though... Then again, there's version pinning when using the module, so it won't be that bad.

Edit: There's a reference to the aws:MultiFactorAuthPresent in the role module, but is that related to the policy's permissions?

ketzacoatl commented 5 years ago

What are your thoughts on this @borsboom?

borsboom commented 5 years ago

The history here is that we typically give every group that has human users a policy that lets users set their own password as long as they're authenticated with MFA, and that's where this variable is used. You're totally right, though, that it's really much more general and could be used to attach any policy to the group. One could also argue that such a group might not need any extra policies attached, or might want multiple extra policies. So this could potentially be made a list instead of a single policy.

I'd also argue that it could, and probably should, be left up to the user of this module to attach any extra policies, since this has nothing specific to do with making a cross-account group. It would make our particular use case a bit less convenient, but I think that would be the correct design.

ketzacoatl commented 5 years ago

I'd agree with those updates you've proposed @borsboom, and I imagine we could make an example env that better demonstrates how to use the modules together in an env.