Hi, everyone, and welcome back.
Now, in today's video, we are going to discuss about attribute based access control, also referred
to as IBAC.
Now, before we start with our ABC Learning, it is important that we first understand the basics of
art.
Back now, Arabic stands for the role based access control.
And in this type of approach, the restriction of access is based on person's role within the organization.
Now, when we discuss about IAM in a place, we implement our back by creating different set of policies
for different set of functions.
For example, you see that there are two users now each user is associated with a different policy.
So first we have the DevOps policy and second we have the security policy.
And based on the restrictions or allowances that you add as part of the policy, user will be able to
perform certain functions.
So this is the back based approach.
Now, there are certain challenges that you might face related to this approach.
So let's go ahead and look into it.
So let's assume that you have this account and within this account you have two different environments.
You have a red environment and you have the green environment.
And let us consider that both of them are production environments.
Now, let's assume that you are using a typical outback based model and you have a central policy call
as an admin access DevOps policy that is associated with this account.
And you have a DevOps team to which this policy is associated with.
Now at this stage we can easily identify that the DevOps team will be able to perform all the functions
on red as well as green environments.
Now, generally in larger organizations you will see that even within DevOps team, certain team members
are responsible for certain part of infrastructure.
So let's assume that this DevOps team has ten members.
Five members are responsible for the red environment, five members are responsible for the green environment.
Now in an approach where you have a central policy like this, all of the ten members will be able to
perform operations on all of the environments and this is something that you might not always want.
So based on this architecture, the DevOps team has access to both the red and the green environments.
Now, what organizations will do to segregate things?
They will go ahead and create two different sets of policy.
Let's assume that you have a policy number one for red environment policy, number two for green environment,
and the five members of the DevOps team responsible for the red environment will have this red DevOps
policy and the other five members will have this green DevOps policy.
And in this red DevOps policy, you only allow permissions on red in green, you only allow permissions
on green.
So this type of architecture is much more better when compared to the previous one.
However, in a larger organizations, let's say in the organizations where there are 20 or 30 different
teams of DevOps or maybe developer system admins, etc., what you'll have to do, you have to go ahead
and create more and more set of policies associated with each group of members responsible for a specific
environment.
And in order to avoid this, you can make use of the attribute based access control, which can prove
to be a much more better approach.
Now, before we go ahead and discuss about APAC, let's revise the basics of the attributes.
So at a high level, overview, attributes are nothing but a key value pair that you associate with
a specific entity.
It can be a user, it can be easy to instance, etc. So in a place these attributes are called as tags.
So this is simple to understand.
Now, when we discuss about the attribute based policy what you will do, you have a single set of policy.
Again, there is no need for multiple set of policies, and within this specific policy there will be
one primary permission, which is to allow, for example, star.
So allow all access to the environment based on the user attribute.
Now, at this stage we know that you have a red environment, you have a green environment, and you
associate the attribute to each of the member.
So the DevOps member one has an attribute of red DevOps.
Member two has an attribute of green.
So in such kind of a policy, the DevOps member one will have full access to the red environment and
the DevOps member two will have full access on the green environment, primarily because of the attributes
that you add at the user level and also the attributes that you add as part of the environment level.
So in this approach, you will have fewer set of policies which are much more easier to maintain.
However, one of the important and the critical aspect here is tags.
So the users, the environment that you create, all of these must be tagged.
Now discussing about the attributes for a IAM user in this screenshot you can see that we have one.
User college user 101 and associated with this user is a tag.
That tag is team as green.
So this would typically mean considering that all the tags are properly set and the policies are correct,
this member would be considered as the DevOps member too, since there is a team of Green and he will
be able to access and perform all the operations on the green environment.
So with this base set, let's go ahead and revise the attribute based access control at a high level
overview.
E back is a authorization strategy that defines permission based on attributes, and we have learned
that attributes are tags in us.
Now, if you look into this specific diagram, I have directly taken it from the documentation so that
in case if you are going through it also becomes easier to revise.
So you see that there are three different environments.
You have red, yellow and blue and there are different set of users and clients and associated with
each user and client, there is a specific attribute.
So the user with the red attribute will be able to access the resources that has the red attribute again,
so you can consider to be red environment, yellow environment, blue environment and so on.
So with this base set, let's go ahead and have a quick demo to understand how things work.
Now for today's video, I have two EC, two instances.
One is as part of the red environment.
Second is as part of the green environment for the EC two instance, which is associated with the red
environment.
If you look into the tags, the theme here is red.
So this is the important tag.
And for the green environment, the team here is green.
Similarly, as part of the IAM users, you have two users user zero one associated with a green team,
user zero two associated with the red team.
If we open up the user zero one if you look into the tags again, there is a same tag team of green
and for the user two, you have a team of red.
So the basic idea is that if the tag associated with the user matches to the tag associated with the
resource like EC two instance, then the user will be able to perform the operations that is defined
in the IAM policy.
Now, at this stage I have one common group called DevOps group, and in this group you have both the
users that are added and if you look into the permission, there is only one policy that is associated.
If you look into this policy, in fact, let me edit it now.
If you look into this policy, you have a start instance and stop instance based action that is allowed
and you have a specific condition based on tag.
So here the key is team.
So that basically means that if the team associated with the red environment EC two matches to that
of the team associated with the IAM user, then the user will be able to perform these set of operations.
So let's go ahead and quickly try it out now from a different browser window.
Let me go ahead and quickly log in to the user, one that is part of the green team.
Now if you go to the EC two console, let's switch to the appropriate region.
Let's go to the instances.
Now again, the user zero one is associated with a green team.
Now, if the user tries to stop the instance associated with the red team immediately, you see you
got an error in a similar way.
If the user tries to stop the instance associated with a green environment, you see it is working perfectly
well.
All right.
So I hope with this you understood that a high level overview on how a single IAM policy based on the
attributes can be much more scalable in a larger environment, considering that the resources are properly
tagged.
Now, before we conclude, let's go ahead and manually remove the tag associated with a theme of green
in the green environment.
Easy to.
So I'll just remove this specific tag.
The instance is in the stopping stage, so let's quickly wait for a moment.
So if we refresh the instances currently stopped now from the user zero one which had both the stop
instance and start instance permission, If this user now tries to start the instance immediately,
you see the error has occurred primarily because the tags are not matching.
Now just for simplicity, I have also attached the screenshot associated with the IAM policy.
So in case if you are revising through the slides, it becomes much more easier to understand on how
the background policies are configured.
Now before we conclude, let's go ahead and discuss the benefits of airbag.
First one is that airbag requires fewer set of policies, primarily because you do not have to create
different policies for different job function.
You can create a central policy and based on the tags, the permissions can be automatically managed.
Second here is that the permissions can easily be granted and revoked based on users tags similar to
how we have seen when we remove the tag associated with the EC two instance the permission to enter
it.
Similarly, let's say a user from the green environment is no longer working on the green environment.
He has been assigned some different responsibility.
Then all you'll have to do is you have to remove the green environment tag from the IM user and all
the permissions will go away.
And third primary one is that the attribute based access policy also proves to be quite useful when
you have the users from the corporate directory like Active Directory, and you want to allow or deny
permissions to the US resources.
So that's the high level overview.
And with this will conclude today's video.