AWS Access Control Methods

So far in this Aws IAM article series we have discussed what is IAM & IAM working

Now lets understand what are Aws IAM access control methods:

Role Based Access Control(RBAC):

RBAC is created to hold multiple groups and these group act as containers to hold users who have specific job roles.

So here if you see the below diagram, we have Admin group, Development Group and Operations Group and then we have placed our users inside these groups.

We then take permission policies and apply the permissions policies to the group. So the users inherit the permissions that are assigned to the group and the groups are organized by job roles. it’s a way that you can apply the minimum permissions a user needs for their specific job function. So there will be specific permissions that they have which people in other groups don’t. You’ll find several policies in your account. These are AWS managed policies that are known as job function policies. So these are supposed to be closely aligned to industry specific roles.

Attribute-Based Access Control(ABAC) :
ABAC is where we’re using attributes to control access , in this case tags used to define access to our resources.

Tag: is a piece of metadata. That’s a key value pair

So we have a DBAdmins group in IAM. We have Shiva, who is a member of that group, and Shiva has a tag assigned to his user account that gives him two pieces of information here(key & value). We have the key, which is department and the value, which is DBAdmins. So that’s a tag applied to that particular user Shiva.

So tags are a way of signing metadata to resources using key value pairs. Now, we then have a permissions policy assigned to the group and that permissions policy looks like this.

{
    "Version": "2012-10-17",
    "Statement": [        
        {
            "Effect": "Allow",
            "Action": [
                "rds:RebootDBInstance",
                "rds:StartDBInstance",
                "rds:StopDBInstance"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/Department": "DBAdmins",
                    "rds:db-tag/Environment": "Production"
                }
            }
        }
    ]
}

So let’s try to understand this. Firstly, there’s an effect which is “allow”, so it’s going to allow some access. The action is three different API actions. We’ve got RebootDBInstance, StartDBinstance, and StopDBInstance. The resource is * so it can be any resource, but there’s a condition. So the condition says that the string has to equal, and then we’ve got two particular tags here. We’ve got the AWS principal tag. That’s the tag applied to the user here. So it’s applied to a principal in IAM and that needs to be department/DBadmins. We then have a resource tag. So in this case it’s the RDS database and it needs to have the DB tag environment and the value is production. So the permissions will be granted to the resources when the tag matches the correct value.

So let’s have a look at the tags associated with these two RDS databases.

The top one has an environment of production and the bottom one has an environment of development. So when Shiva actually tries to reboot the DB instance in production, he’s going to get a success because the reboot DB instance action is allowed as long as the department equals DBadmins on the specific principal tag, And the DB tag for the RDS database should equal environment production, which it does.

If Shiva then tries to stop the other DB instance that’s going to fail and that’s because the tag associated with that database but has an environment of development, and that’s not allowed, it’s not in the policy.

That’s all about RBAC & ABAC . Feel free to add your comments and suggestions !!