A Hands-On Tutorial For An Attribute-Based Permission Rights Implementation In AWS

Permission rights are the first on our list as they proved to be a bit tricky. Tagging resources and binding permission rights to them using these tags is a simple and straightforward way to manage access rights in AWS. Let us show you how to do it in the AWS Management Console.

Main Tools

Access rights or permission rights specify what you can do – mainly if you can perform changes or not – and where.

AWS allows you to define those rights on a very granular level. There is no general read or write access to an AWS service, account, or resource. Instead, it offers additional types of access. For instance, the list type allows to list resources without being able to look into them.

Besides, AWS breaks every service into features that can be accessed in a different way each.

In AWS, you can shuffle these rights as you want. Five main concepts help you in customizing your perfect permission concept.

IAM Users

IAM users are AWS identities that are bound to a root user (AWS account). Every IAM user has different access credentials, such as username and password, and may be assigned different permission rights later.

Policies

A policy is where everything starts: it can be seen as an actual list of access rights. As already mentioned, for every item on the list you have:

an access type (read, write, list, tag, manage permissions)
a scope of application: a service (mandatory), action, or resource

In addition to that, AWS policies can include request restrictions by checking the request against various conditions, such as the source IP, time, resource tags, protocol etc.

Roles

Roles are AWS identities that allow IAM users to switch between more granular levels of access. You can attach different policies to different roles and then assume any of the roles in order to restrict or expand access to services or resources while acting as the same IAM user.

Roles are advertised as fool-proof: AWS recommends you to assume only read-enabled roles as long as you are not intended to make any changes but only want to browse your resources.

User Groups

User groups allow you to share policies between multiple users. They also enable you to create various combinations of policies instead of creating complicated policies and prevent you from losing an overview of those as a consequence of their complexity.

Practical Implementation

We took EC2 as an example to show you the power of policies, roles, tags, and user groups in action.

Goal

Various scenarios are possible for specifying permission rights for EC2.

Let’s try to separate access to instances based on their tags. For instance, you can empower some users with access to all instances and others to only selected ones. That would be a typical use case when you grant permissions based on the team membership and which instances a team is working with.

By using this scenario, we focus on the attribute-based access control (ABAC).

Prerequisites

Just a short recap on what you need to make your hands dirty on the AWS security:

The biggest part of it is done in your root account.

Our Plan

Here comes the spoiler of what we are going to do:

Tag an EC2 instance.
Create a policy that allows to see all EC2 instances (which is required for the AWS GUI to work properly) and to start and stop instances with a certain tag.
Create a role and attach that policy to it.
Create a policy that allows to assume the role we created in the previous step.
Create a group so that the assume-role-policy can be attached to multiple users.
Add some users to the group.
Add the role in the role switcher.
Start switching roles.

Afterwards, you can repeat these steps to add a role with different permission rights.

Steps

Tag Your EC2 Instance

In your EC2 console, you’ll land in the instance list.

Click on the instance ID.
Select the Tag section.

Click on Manage Tags and then Add tag.

We will use an access tag and give it an admin value.
Go through the same steps with your other EC2 instances. The value must vary and match with the role you want to use it for, e.g. use such values as developer, tester, etc.

Create Two Access Policies

In your IAM console, go to Access management → Policies.
Click Create policy‍
Choose EC2 in the Service section.
Expand List and select DescribeInstances, which allows you to list all instances so that you can later access one of them in the GUI.

Note: AWS prepared quite a few default policies for the most common use cases. Feel free to scroll through them. By clicking on the plus, you can get to a JSON view. However, we need to create a custom one.

Notes:

You can import policies as JSON files and then adjust them in the JSON editor. That comes in handy if you want to reuse policies between services or accounts.
If you have a lot of permissions to grant, it may be easier to deny the few ones that you do not want to grant.

Click Add additional permissions.
Select EC2 as a service.
In the Actions, in the Write subsection, tick StartInstances and StopInstances.
In the Resources section, select All resources. We will deal with limiting it to only certain resources at the next step.
In the Request conditions section, click Add condition. It’s a kind of a workaround but fulfils its purpose.
Click Condition keys, scroll down to Service level condition keys, and select aws:ResourceTag.
Enter access as TagKey.
Select For any value in request as Qualifier.
Select StringEquals as Operator. Note: You can also choose StringLike or any other operator. StringLike helps you to detect string patterns in your tags in the same manner as the SQL LIKE operator. You can use it to shepherd a few tags into one policy.
Enter admin as value.

If you created multiple EC2 instances on the previous step and want to try out different roles and access levels, you can copy this policy from the JSON editor and only replace admin with other tag values to generate new policies.

Click through the next section and give your policy a name. We recommend using “Policy” somewhere in the name. That helps you to distinguish between different AWS objects.

Create A Role

In your IAM console, go to Access management → Roles → Create Role.
Select AWS account in the trusted entity type.
Select This account. It is easier to learn with your own account first.

Notes:

To be created, a role needs to be bound to an account. It can be then shared between IAM users in the same account.
Role names can be paths made with slashes.

Attach the policy we just created.
Repeat for other policies.

Create A Policy To Assume The Role

As we mentioned before, switching between roles is a kind of feature that needs its own permissions policy to come into effect.

In the policy editor, select STS (Security Token Service) as a service.
Inside Actions, go to Access level → Write → Assume Role.
In the Resources section, leave Specific selected.
Click on Add ARN, and type in the exact name of the role.
The account number will be added automatically.

As this role is bound to the previous role, you will have – as you may already guess – to create more of them, one per each resource.

Create A User Group

In your IAM console, go to Access management → User groups → Create User group.
Add users.
Attach our assume-role-policy (not the actual access policy!)
You’ll need one user group per each role/access level/policy.

Add Roles To The Switcher

Now, log out of your root account.

Log in to your IAM user (the one you added to the group on the previous step).
In the top right corner, click on your account name.
Note your account number, you’ll need it later.
You’ll see the Switch role button Click on it.
On the new page, click Switch role again.
You will need to enter manually the following: 1) Your root account number and 2) The name of the role.
You will be able to see your roles in the role switcher like this:

Note: This information is only saved in your current browser. With a new one, you’ll have to go through adding roles in the role switcher again.

Now, Try to access the EC2 service using different roles.
You must be able to look into only selected ones for non-admin roles and into all for your admin-tagged role.

A Short Recap

To implement ABAC, you need to remember this chain:

actual tag-based access policy → role → policy for assuming that role

Possible Shortcuts

We made this example as complicated as possible to cover all possible scenarios and to express our preference for resource tags as a flexible tool.

Indeed, you can skip everything that involves them and limit your policy granularity to the service level.

You can also attach policies directly to a user without creating a group and adding the user to it.

Other Things To Know

Tagging S3 buckets won’t work with this scenario. Natively, AWS offers you to list buckets in a policy, under Resources. Indeed, if you remove a bucket and create a new one, you’ll have to adjust all affected policies.

The good news is that you can replace a lot of what we did in the IAM GUI with a few commands in AWS CLI. That is worth another tutorial, though.

Conclusion

AWS may require some clicking around and reading a lot of its documentation before you can start feeling confident about it.

We tried to provide you with straightforward instructions as the original AWS docs often spread one simple concept across multiple articles. Eventually, we want you to be able to implement both RBAC and ABAC and experience the flexibility of the latter.

We will continue to share other practical tips in our Your AWS Account From Scratch blog series.