Tuesday 18 February 2020

AWS - Cross Account access using #IAM

Access multiple AWS accounts

Amazon says that you should have an account for different services, projects and clients.
This can get confusing very quickly, as you may end up with many many user ids and passwords.

There are many tutorials and follow-me videos on this topic but they can very confusing.
Personally I have found these two useful:

How to do it?

Let's assume you have two accounts ROOT and CLIENT. (Most examples have dev and prod and the like, but that does not give the relationship).
The ROOT account is where you control all the users and the account that is your main account. The account that pays for everything.
The CLIENT project could be where you host some lambdas for a specific client. An account you want to keep separate.

Step #1 - Root account number

Take note of your ROOT account number.
This can be found at the top of this page in the console: https://console.aws.amazon.com/billing/home?#/account

Do the same for your other account.

Step #2 - Set up cross-account access in the ROOT

Log into your ROOT account.
In IAMS create a policy called CrossAccountAssumeRole.
All this role needs to do is allow all actions on STS and for all resources.
Create a group called CrossAccount with this role attached to it.
Place the users who you wish to be allowed cross-account access the new group.

Step #3 - Allow your other account to connect to the ROOT

Log in to your other account CLIENT.
Create a new policy for your cross-account user to be assigned when it assumes its role.
This is important as this is the role that will define what your other account is allowed to do.
It will not be a Group or User ... its a role!
A useful AWS defined policy for cross-account admin is ... AdminsitratorAccess ... so we will use this.

Click create Role;
Select the trusted entity as "Another AWS account";
This will ask you for an account id. This is the id of the ROOT account (step #1).
This is important as it is to establish trust between the CLIENT and the ROOT. 
And no I don't know why sub-accounts don't trust the ROOT account implicitly.
There are two checkboxes on that screen for MFA and external ID ... either ignore them or add MFA.
Attach as many or as few policies as you need the role to have.
You will be asked what the users who can have this are ... ignore this for now.
Call the role "MainAccountAdminRole".

You can create many roles this way and as you might create User groups the Roles can be for any purposes.

Step #4 - Assume the Position role

Now log out and back into the ROOT account;
On the menu bar under your login name will be the option "Switch Role";

You will be presented with a screen asking for Account.
This is the account CLIENT Id from step #1, ... type it in.
You are asked for the role ... this is the role you just created in step #3, .. "MainAccountAdminRole".
Add a nice display name ... "Client" and a colour.

Then click switch role.

And you are in!

Beware!

There are some bear traps along the way here so be mindful:
- The role in the CLIENT account can do anything it is assigned to do. So admin access could be dangerous
- The "Switch role" settings exist in your browser cache. So you will need to set up the switch roles for new browsers, etc.


-- Enjoy!