Welcome to this lecture covering the principles of cross-account access. Firstly, let me quickly define what cross-account access is. Put simply, it allows IAM users from one AWS account to access services within a different AWS account through the use of IAM roles. Now, IAM roles allow users and other AWS services and applications to adopt a set of temporary IAM permissions to access AWS resources.

But why would you want to implement cross-account access in the first place? Well, essentially it comes down to architecture and security best practices. For example, most organizations using AWS will probably have a production and a dev or test environment. For ease of management and isolation, it's likely that each of these environments will be in separate AWS accounts. With this in mind, your development team who primarily work in the dev account may occasionally require access to resources in the production account. Instead of creating additional user accounts in the production environment, which would only be required on a rare occasion, roles could be used with the required permissions instead. The development team could then be granted permission to assume this role to then access the resources in the production environment. This helps to adhere to the principle of least privilege.

As this access is not always required, the developer must consciously switch to and assume the role to access the other resources. For additional security, you could also add multi-factor authentication to the role before it can be assumed, adding another verification step.

Let me now look at the key steps required to implement cross-account access. To understand this process, you need to be aware of two key terms that I will be using. These being the trusted account, and the trusting account. Using our previous example of production and dev, the production account will be the trusting account and the development account would be the trusted account, as the development users will be trusted to access the resources in the production account, which is trusting those users.

Let me break the process down. Firstly, you must create a role from within the trusting account, which in our example, would be the production account. This is to establish a trust between the two accounts. This role will define the development account as a trusted entity. Next, you must specify the permissions attached to this newly created role which the users in the development account would assume to carry out their required actions and tasks. Next, you must switch to the trusted account, in this scenario the development account, to grant permissions to your developers to allow them to assume the newly created role in the trusted account. Finally, you can test the configuration by switching to the role.

Now we know the fundamentals of this process, let me provide a demonstration on how to configure this using the AWS Management Console. Okay, so I'm logged into my AWS account, as you can see I'm on the AWS Console, and this is going to be my trusting account. So from here, I need to select IAM to allow me to create the role. So under Security, Identity, & Compliance, we can see the IAM service, so if we select that. Go across to the left-hand side and select roles. And at the top you can see a blue button called Create role, so let's click on that. And here I need to select the type of trusted entity. Now, because I want this role to be assumed by another account, I'll select this option here, the second option where it says Another AWS account. And underneath here you have a couple of options, and here we need to enter to account ID and this is the account ID of the trusted account. So let me just go ahead and enter the account number of what will be the trusted account. And if you wanted to add multi-factor authentication then you can select this tick box here. For the sake of this demonstration, I'm just going to leave that unticked. Once we have the trusted account ID entered then we click on next for permissions. And here we specify what permissions we want assigned to this role to allow the users in the trusted account to assume. So let's just enter EC2 and we'll give them EC2FullAccess. Once you've assigned your permissions, select Next. 

If you want to add any tags for this role then you can enter that here. For this demonstration, I'm just going to click on Next. And finally, we get to give our role a name, so I'm just going to call this CrossAccountDemo. We can add a description if we want to. And we can see here that the trusted entities is the account ID that I entered. So this is a different account from the one I'm in at the moment. And also you can see the policy that I assigned here. 

Okay, let's create this role. And there you see it, the role CrossAccountDemo has now been created. So now we've set up the role and we've added the trusted account as the entity of this role, let's now swap over to that account to allow the users in that account to assume this role within this account. So let me just flip over to that account now.

Okay, so I'm now in the other account, as you can see up here it's a different account number. And this is the account number that I added as the trusted entity on the role. So if we go down to the IAM service from here. And I want to assign some permissions to one of my groups, and I'm going to assign it to the developer group. So if I select this group here, we can already see that this developer group has a number of policies that allow specific access within this account, but I want all users in this group, and if we just click on the Users tab, we can see that there's two users here, and one of those users is the account that I'm logged in as at the moment.

So, I want all users of this group to be able to assume that role that we created in the trusting account. So I'm going to create an inline policy. So if I click on Inline Policies, it says there are no inline policies to show, to create one click here. I'm going to create a Custom Policy, click on Select. Give the policy a name and I'll call this CrossAccountAccess. And I've already created a policy for this, so let me just paste this in and I'll just run through it. So, what this policy does, it allows the AssumeRole action for the role that I created in the other account, and as we can see, that is the account number of the trusting account where the role exists, and that's the role name. So when you're setting this up on yours, just make sure you have the account number of the trusting account and also the correct role name that you configured for your own.

So, once that policy's created, if we just click on Validate Policy, we can see that the policy is valid, and then click Apply Policy. And if we have a look, we can now see the policy under Inline Policies. So again, just to reiterate, now any user within this group is able to assume the following role, and that's the role that we created in the trusting account.

So now that permission is set, let me see if I can switch roles. Now, to do that, if you go to the top of the screen here where it shows who you're logged in as under what account and click on the dropdown list, and then at the bottom we can see Switch Role. So if I click on Switch Role. So if I enter the account number of the trusting account, and then the role name, which was CrossAccountDemo, and then select Switch Role, we can see at the top here that we're now logged in under the CrossAccountDemo at the trusting account.

Now, when you assume a role, the permissions you already had are replaced with temporary permissions of this role. As a result, I can see a lot of errors within IAM here, because I don't have access to IAM. If you remember, the only permissions we allowed on this role on the CrossAccountDemo role, was full access to EC2. So that's why I'm getting all these errors on IAM. However, if I go across to EC2, we should have permissions to launch an EC2 instance. So if I go down to launch instance, and go through the process, we can see that it's allowing us to go through. Now, on this page, you'll notice that there's an error here as well; it says I do not have permissions to list instance profiles, and this is because this element here is related to IAM and I don't have access to IAM with the CrossAccountDem role - I only have access to EC2.

So I'm not allowed to select any IAM roles for this EC2 instance. However, I can continue to go through and accept all the defaults and launch an instance. And as you can see, that instance has now been launched. So I've got access as per the permissions of the role. And remember, this instance is actually running in the trusting account because that's the role that I assumed.

So if I logged back into the other account now, we should see this same instance running. And let's just give this a name: Cross Account Instance. So if I go back to my original account which is CloudAcademy, we'll see that this EC2 instance isn't running because it's in the wrong account. So let's take a look. And now I've come out of assuming that role, we can see that in the trusted account there isn't actually any EC2 instances launched because it was in the trusting account. So let me now log back into the trusting account and we should see that EC2 instance that we launched when we assumed the role. So let me flip over to that now. So I'm now back in the trusting account and here we can see that the instance is here that we created when was in the other account and assumed the role. So that's how you create and configure cross-account access.