AWS IAM roles and policies explained

In this article, I am going to explain the essential parts of IAM and describe how to grant permissions to your users or AWS Lambda functions you wrote.

Users and groups

Those two concepts are easy because almost every computer system that has users allows us to group them and specify permissions of the entire group.

Let’s start with the users. In IAM, the user is someone or something that has credentials and can be authenticated by AWS. We may create user accounts for people and software which need access to AWS.

We may assign those user accounts to groups. When we have a group of users, we may specify that the whole group has access to some service.

Roles

In addition to groups, we have user roles. A role is just another way of granting permission (or a set of permissions) to a user. The critical distinction is the fact that we can give a role not only to a user account but also to many AWS entities such as AWS Lambda, EC2 servers, etc.

When we want to give access rights to a Lambda function, the correct way to do it is to define a role for that function (or use the one created by default when you don’t specify an existing one) and grant permissions to that role.

Similarly, when we run a custom application on an EC2 server, we don’t create a user account for that application and hardcode the credentials in application code (seriously, don’t ever do it). Instead of that, we add the access rights to the IAM role used by that EC2 instance.

Policies and permissions

I used the word “permission” a couple of times, but they don’t exist in AWS. Instead of permissions, we define what actions are allowed (or denied) and what resources can be accessed while performing those actions.

To define permissions, we must create a policy. The policy consists of a set of allowed actions. We may be very specific and describe precisely what can be done and what can be used to do it.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
  "Version": "2012-10-17",
  "Sid": "ReadOnlyAccessToS3BucketAndDynamoDB",
  "Statement": [ 
    {
        "Effect": "Allow",
        "Action": [
            "s3:ListBucket",
            "s3:GetObject",
            "dynamodb:GetItem"
        ],
        "Resource": [
            "arn:aws:s3:::some-bucket",
            "arn:aws:s3:::some-bucket/*",
            "arn:aws:dynamodb:eu-central-1:1234567890:table/sometable"
        ]
    }
  ]
}

On the other hand, we may define a very lax policy by using the * sign instead of a specific action or resource name. For example, the following policy allows performing every available action on every resource in S3.

1
2
3
4
5
6
7
8
9
10
11
{
  "Version": "2012-10-17",
  "Sid": "DoWhateverYouWantWithMyData",
  "Statement": [ 
    {
        "Effect": "Allow",
        "Action": "s3:*",
        "Resource": "*"
    }
  ]
}

Just to be clear, don’t copy it. You should always provide access to data on a need-to-know basis and give the least permissive rights that allow getting the job done.

It is crucial to know that if we define both allowed and denied actions, the denied actions take priority, and overwrite permitted actions.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
{
  "Version": "2012-10-17",
  "Sid": "DontReadThatOneFile",
  "Statement": [ 
    {
        "Effect": "Allow",
        "Action": [
            "s3:ListBucket",
            "s3:GetObject"
        ],
        "Resource": [
            "arn:aws:s3:::some-bucket",
            "arn:aws:s3:::some-bucket/*"
        ]
        },
    {
        "Effect": "Deny",
        "Action": "s3:GetObject",
        "Resource": [
            "arn:aws:s3:::some-bucket/cant-touch-this"
        ]
    }
  ]
}

When we have a policy, we can give access rights to users (or EC2, lambdas, other AWS services) by assigning that policy to a user account, group, or role. You can do it either using the web interface or via AWS CLI:

1
2
# in this example, we attach an existing policy to a role
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/DontReadThatOneFile --role-name SomeRoleName

Did you enjoy reading this article?
Would you like to learn more about software craft in data engineering and MLOps?

Subscribe to the newsletter or add this blog to your RSS reader (does anyone still use them?) to get a notification when I publish a new essay!

Newsletter

Do you enjoy reading my articles?
Subscribe to the newsletter if you don't want to miss the new content, business offers, and free training materials.

Bartosz Mikulski

Bartosz Mikulski

  • Data/MLOps engineer by day
  • DevRel/copywriter by night
  • Python and data engineering trainer
  • Conference speaker
  • Contributed a chapter to the book "97 Things Every Data Engineer Should Know"
  • Twitter: @mikulskibartosz
Newsletter

Do you enjoy reading my articles?
Subscribe to the newsletter if you don't want to miss the new content, business offers, and free training materials.