Hear you and welcome back now in today's video, we will be implementing the cross account and rule
from scratch.
Now before we do that, let's go ahead and quickly revise the architecture here.
So basically you have to settle for comes first.
One is the default as the identity are gone.
So identity account is where the identities are stored and what identities, identities are IEM users.
And then you have various other accounts where the actual resources are great.
It can be a stablecoin.
It can be easy to instances and so on.
So the architecture is the IEM user belonging to this identity account.
And then, depending upon the permission of the user, he can login to account B, account C or whatever
IWC accounts are present through the assumed roll functionality.
Know the overall steps that are involved are three fourths.
One is you have to create a user account, so the account is nothing but the identity account.
Then you need to create a closed account role in Account B..
So cross account control is where you go ahead and create the IAM role, and this IEM role is what the
IEM users from the identity account will be assuming.
And then the third step is allow users to switch to account B roles, so the IEM user data stored in
the identity account.
That user also needs the permission to assume this role so that permission you'll have to give in the
identity account.
So again, it might be a little confusing right now.
Les Gordon implemented from scratch and then it will become very easy.
So the first step first create a user account.
Now for today's demo, I have two accounts.
First one is the identity account.
So you see, I have given the name to this tab caller's identity database and the second account that
is running in a second that will be reflected as the Account B..
So first, as you're discussing, the step one is to create the IEM user in the identity account.
So let's quickly do that now from the IEEE.
Let's go to users and let's go ahead and create a new user.
The name led this call more and will give the eatables management control access.
Let's also quickly set the password for bulb user and we remove checkbox associated with creating a
new password while signing and now will not be giving any permission to the bulb user here.
Since this is an identity card?
Great.
Alright, so our step one is created, so our bob user is created in the identity icon.
Step two is to create across a control in account.
To be so icon, we will create a new closer control.
So let's go to the second tab and within here.
Let's also open up the IEM service and within yet will go ahead and open up rules and let's create a
new rule.
Now within here you have multiple options.
One among them is another eatables account, so let's go ahead and click here.
And now what that is asking it is asking for the account I.D. So this account ID is where you put the
account idea of identity icon.
So let's copy the identity account idea and paste it once.
Then let's do a next.
And now it is asking for the permissions.
So what this basically means is that once the IEM user from the identity account assumes this role and
connects to the account B, what are the permission that this user must have, whether he must have
access to S3, access to easy to and so on?
So what we will see the user should have access to, let's say S3.
So I'll see S3 read only access, let's do.
And next, I'll do a review and the rolling, let's call it as close account account B will go ahead
and create a grid so our role is created.
Let's quickly open this up.
Now you see, for the cross account and role, you basically have one more option which states give
this link to user who can switch their role in the console.
So if I bulb bob user from the identity account wants to connect to the Account B, then he has to go
ahead and click on this specific link.
So this is one part.
However, before we do that, let's complete the third step, which is allowing the user to switch to
account it.
So currently what has happened is our user is created an identity account and that user does not have
any permission.
So that means that the bulb user will not even be able to go ahead and connect to the gross account,
i.e. role account B.
So we have to give minimal permission to bob users so that he can at least connect to the IEM role of
different eatables accounts.
So that permission is what we will be giving in this step three.
So going back to our first tab, let's click on.
Laws and Florida, Bob user, let's go ahead and create a new policy, so I'll either in inland policy,
let's open up Jason.
Let me quickly zoom in COVID-19.
Let me go ahead and beast assemble policy that I already have available.
I'll be pasting this policy after this video so that you can also try it out and within the action.
This is this is a Zoom role, so that basically means the Bob users should be able to assume the role
and then we have to give the area and associated with the parole associated with the account be.
And in the resource you see, you have to basically give the Raleigh area.
So from the account, be let, let's copy this role here anyway, and let's go ahead and be state audio.
So are Bob.
Users will be able to perform a Zoom roll operation to this specific cross account.
Are going to be ashamed.
Let's do a review policy in the name.
Let's call it as see a Zoom.
All are going to be and we'll create a policy grade.
So all of our three steps are now completed.
So the only thing that is required to test is to log in with the bob user in the identity account and
then using the link that we were provided at the account b level will go ahead and see on how Bob can
switch to account B. So from the identity account, let's go back to their dashboard so that we can
get the log in link.
I'll quickly zoom out.
So this is the sign in your head and from a new tab.
Let's go ahead and open this up.
I'll specify Bob and I'll also specify the password.
Great.
So at this stage, Bob is logged in to the identity account.
Now do remember that you should not give any permission to the AM users in the identity account.
All they should be able to do is perform across account and role based action.
So no from the account B. Let's copy the sign in link and from our Bob music.
Let's go ahead and paste strict.
So it will basically ask you for the display name.
Let's just call the screen.
Names are gone.
Be and let's do a switcheroo.
And now you see the bob user is logged in to the account B. Now, since Bob User has the S3 access.
Let's quickly verify if he can open up this tree service.
And yes, he's able to see the three console in a similar way.
If you would look into the cross account rule, the only access that we had given was a three read only.
So if Bob tries to open up the easy to console, he should get an error.
And as expected, he's getting an error over here.
No one Steve Bob user.
Let's assume that he has completed his work in the account b he can switch back to his own account.
So when you do a back to back now, what will happen is from there are going to be Bob will come back
to the identity icon.
So this is basically an identity account here.
And even if the identity account, he'll get this error and in a similar way, when he tries to open
up the S3 in the identity icon, he should get permission did anyway, say here as well.
And as expected, you see you basically get a permission denied message.
Great.
So I hope with this you understood the basic architecture of a cross account and it would again, I'd
really encourage you to go ahead and try it out.
This is very common across most of the organization and the organization that have not really implemented
such approach.
You are the one that can do that.
So with this will go ahead and conclude today's video.