I’ve implemented the AWS multi-account setup a few time now, splitting all users and groups in one Root account, from the environment resources which are in separate accounts.
Logging to the root account to then switch role over an environment account works like a charm, but I don’t have a DRY solution for the following part :
Say I define an access role in account A, and a Group in account R (root) that allow members of this group to assume the role defined in account A (for the sake of gaining access to account A from account R), the policy attached to aforementioned role is similar to:
how do I avoid referencing the role by its arn in terraform when building this policy? I’d like to use a remote state datasource to get the role arn, but terraform executes in the context of the root account and the account referenced in the role arn is the environment account, not the root account.
Unfortunately, I don’t know of any tricks to be able to do retreive a remote state value from a different account. The way we currently handle it is by copying/pasting the ARN manually.
Actually, after chatting with @jim, he had a good suggestion…
How about if you set a policy on the remote state S3 bucket in Account A to grant access to the root account? Then, you should be able to use remote state as normal.
yes, @jim’s suggestion should work as after all S3 buckets are global ! I was locked in a “this belongs to this account / VPC point of view”. I’ll try and report back, but I see no reason why it should not work.
by the way, in a multi-account deployment with a root account dealing with user management and access control among other things, do you usually use a separate bucket to store each environnement account states? or do you use a single bucket owned by the root account?
I noticed yesterday that the terraform team vaguely suggest to use a unique repo (see here ).
I myself use several per AWS account (splitting infrastructure and services). I’m looking for feedbacks and pros/cons.
Obvisouly access control over states and separation of concerns/responsibilities are part of my pros.
We typically use a separate bucket for each account. State files can contain secrets, and if you corrupt a state file, it can cause serious issues, so the isolation between accounts is generally a good thing (that’s why we use separate accounts in the first place!).
Interesting, I hadn’t seen that before. It seems to be that having all the state/control in one account largely defeats the purpose of having multiple accounts in the first place.