Skip to content
This repository has been archived by the owner on Jul 11, 2023. It is now read-only.

Documenting cross account modules usage #182

Open
bugok opened this issue Nov 13, 2018 · 5 comments
Open

Documenting cross account modules usage #182

bugok opened this issue Nov 13, 2018 · 5 comments

Comments

@bugok
Copy link
Contributor

bugok commented Nov 13, 2018

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
Copy link
Contributor

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
Copy link
Contributor Author

bugok commented Nov 14, 2018

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
Copy link
Contributor

What are your thoughts on this @borsboom?

@borsboom
Copy link
Member

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
Copy link
Contributor

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.

@ketzacoatl ketzacoatl added the P1 label Feb 28, 2019
@ketzacoatl ketzacoatl added P2 and removed P1 labels Jul 12, 2019
@ketzacoatl ketzacoatl added this to the v0.9.1 milestone Jul 12, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants