Hi, everyone, and welcome back.
Now in today's video, we are going to discuss about the identity account architecture.
So nowadays in most of the organizations that you will see, there are two primary types of architecture
that are generally very common.
First one is the identity account architecture, and second one is based on single sign on and hence
it is important for us to understand them.
And in today's video, our primary focus is going to be the identity account architecture.
So not only this is important from the exam perspective, but it is also important from the production
standpoint.
Now, before we go ahead and understand more in detail about this type of architecture, it is important
for us to take a step back to understand what was the type of architecture that organizations generally
used to use in the earlier days when it was gaining traction.
So during the earlier times you would see that most of the organizations had a single account.
So all of the resources, all of the servers that were created were in the single account only.
So in such cases the management was very simple and every user who needed access to a diverse account
had a single set of username and password and a single set of access and secret key.
And generally what used to happen was this account was divided.
There was a division based on the region.
One region was used for development environment, second region was used for production environment.
So the developers had the access to a development environment region and the team security team had
access to both the development and production.
So this was generally very common in the early days.
And in fact nowadays in many of the small startups you will still see such type of architecture being
commonly used.
Now when the organizations become big and they have hundreds of servers, a single account based architecture
is not very suitable and you also have to be very careful in your IAM policies.
For example, you have added a new developer to your account and by mistake you gave him access to the
easy to instance, but you forgot to specify the condition of the development environment region.
So now what will happen is that the developer will have access to both the development as well as the
production regions over here.
So this again creates certain set of challenges and you have to be quite careful within your IAM policies
and hence when your organization's becomes big it is important that you have a better architecture with
better isolation.
So a better architecture that you will generally see being used extensively nowadays is individual account
per function.
So you have to account for development environment account for staging a account for production.
So in case if developer wants access to the place he wants to do some testing, he can get access to
the development environment.
Now, although this is a great type of architecture, it comes with its own challenge.
One of the primary challenge that you will see is that each user will have a different set of username
and password for each account and a different set of access and secret key for each account.
So for example, let's say a security team now security team will have to monitor all of these three
accounts.
So a security team member wants to log into the development account.
He will have its own username and password if he wants to perform some operations via a different set
of access and secret keys are required.
So when you have, say, 100, a lot of organizations have hundreds of accounts.
So in such cases, having 100 different username and password, 100 different access and secret key
is very difficult to manage.
So to overcome this, you have an architecture of identity account.
So what happens in an identity account based architecture is that all the IAM users are stored in a
central database account you can refer to as identity account.
You can refer to as a central account, or you can give a different name as well.
So if you see in the diagram in the identity account, all of the IAM users are stored and you create
a configuration in such a way that the users from identity account can log into development environment,
they can log into production environment directly without having a separate set of credentials.
So again, it's not that any user can log in to develop an introduction.
It all depends upon the policy that you add at a user level.
He can either log into development, either log into production or both.
So this is the basic idea of identity account.
Only one set of credentials are used.
No separate username and password are created for each of the accounts.
So with this base set, let's go ahead and have a quick demo.
Now for today's demo, I have two tabs that are open and in each step we have a separate account.
So in that tab, number one, if you see it is referred to as an identity.
So this is the identity account and the tab number two is referred to as a production.
So this is a.
Introduction account.
No.
In the identity account you will see that a user of Alice has logged in.
Now let's say Alice user wants to access the production account.
Now in this case, as we are discussing, since we have an identity account base architecture, the
ALICE user will not need to be created in the production account if the access permission is there,
alice user can directly log into the production account.
So from the identity account what Alice user can do, she can provide the sign in link if you see it
is signing link associated with the production account and the production account number is also given
and it is ending with four, seven, six three.
So as soon as the ALICE user adds this, the switch role base configuration appears and all that needs
to be done is switch role.
And now you see Alice user has logged into the production account.
You can even see from here you have see hyphen production followed by the account number and if you
look into the account number it's ending with four, seven, six three and if you look into a second
tab belonging to the production account, this also ends with four, seven, six three.
Now let's say Alice user has completed the appropriate work in production account.
Then Alice user can go ahead and switch back and now Alice is back to the identity account.
And later let's say Alice user wants to do some testing in the development account similar to how she
had switched to the production account.
The approach remains to be similar.
Now one more thing.
Since Alice had switched to the production account, if she wants to do it again, the role history
remains to be here.
So all she needs to do is she has to click on the production.
So as soon as the user clicks, she goes back to the production account.
All right.
So I hope at a high level overview you understood the architecture of identity account.
So irrespective of how many accounts are there, you have 100 accounts, 200 accounts, etc. It does
not matter.
All that you need to do is you have to give access to the user in the identity account so that the user
can log into the identity account and from here they can log into all of the other accounts depending
upon the permission that the user has.
Now, at a high level overview, if you discuss the practical architecture, there are three steps that
are generally required.
First one is that the user needs to be created in the account.
A account is nothing but the identity account.
The second is you have to also create a cross account role in the account.
B So let's say that the Alice user has logged into the production account.
Now what is the access that the Alice user will have?
Will she have access to a three?
Will she have access to E two instance and so on?
So all of those things are defined in this specific cross account role.
And the third is you allow the users to switch to the account B role.
So you give permission to the user in the identity account so that she can switch to development, production
or any other account depending upon the oral permissions.
So these pointers can be easily understood with this practical architecture.
You have an identity account.
All the IAM users are present, you have a cross account, IAM role in each of the account where you
want the users to connect directly through the identity account and then the users can perform the role
operation to connect to this specific account.
Now you'll see in the account b you have a permission of S3 bucket in the account.
C You have the permission of easy to instance.
So if a user has logged into account C, the user will only have access to E two and no other services.
So let me quickly show you that as well.
Now in the account of production, let's quickly open up the IAM and within here I have a role of C
hyphen production.
So if you would have noticed this user has used this role which is C hyphen production.
Now what is the permission that this role has?
The only permission that is attached is the S3 read only access.
So if Alice user tries to open up the easy to service over here, you see immediately you get an error.
So the only permission Alice has is the S3 access.
So if you try to open up the S3.
You see, all of the buckets are appearing warrior grid.
So this is the high level overview about the identity account architecture.
And in the next video we'll go ahead and look into it in a practical point of view so that our understanding
is solid and clear.
So with this will conclude today's video.