Amazon Web Services (AWS) references a dizzying number of concepts, resources, patterns, and best practices to provide a fully managed solution for authentication and authorization. From a big picture perspective, there are three services that AWS offers for authentication and authorization - Identity and Access Management (IAM), AWS Cognito, and AWS Single-Sign-On (SSO). This post is a first of a two-part series that condenses the concepts and explores few use cases. This post is about IAM.

IAM is a collection of AWS resources. The following diagram puts all the concepts in a single perspective.

In addition to the above, there are three more things to understand.

AWS Organizations

A system administrator can use IAM roles, resource-based policies, or access control lists (ACLs) to manage cross-account permissions. However, AWS recommends using AWS Organizations for this purpose.

Attribute-Based Access Control (ABAC)

ABAC is a more scalable solution to authorization than a traditional Role-based access control (RBAC). The scale is because ABAC policies allow operations when the principal's tag matches the resource tag and requires fewer AWS policies changes.

ABAC vs. RBAC with an example

A system administrator (sysadmin) wants to manage access to three projects: alpha, beta, and gamma. In the RBAC scenario, the sysadmin will create three roles with appropriate policies and trusted entities. When developers create additional resources, the sysadmin will modify the impacted policies to allow operations on the new resources. However, in the ABAC scenario, the sysadmin would set up the policies to allow operations matching a tag, say project with the project names. Thus, when developers create new resources, they carry their project tag, making them accessible immediately to other developers in the same project.

Secure Token Service (STS)

AWS STS provides principals dynamically generated temporary security credentials (access key and secret key). These credentials work identically to the long-term credentials associated with an IAM user, with the crucial difference that they are short-lived from a few minutes to a few hours and not stored with the user. STS is typically involved in identity federation with SAML and OIDC. It will come up again in the next part of this series when we explore AWS Cognito and SSO.

Use Cases

Use cases typically involve providing an AWS user or service authorization to a resource.

EC2 access to S3 using IAM role

In this setup, an application (APP) running on an EC2 instance does not have privileges to access an S3 bucket. The application in the examples is the AWS CLI.

The default configuration uses the security credentials of a user with no privileges. Therefore, trying to access the S3 bucket will result in an error.

[ec2-user@ip-a-b-cd ~]$ aws s3 ls s3://bucket-name/ 
 
An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

Next, the EC2 instance is given an AWS Role with permissions to access the bucket. The policy that provides the "list" permission looks like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:ListJobs"
            ],
            "Resource": "*"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::$bucket-name"
        }
    ]
}

After clearing the credentials of the unprivileged user, invoking the aws s3 ls command shows the contents of the bucket. Clearing the credentials is necessary, otherwise the application will not be able to use the permissions attached to the instance.

User access to S3 using IAM role

In this use case, an IAM user does not have privileges to access an S3 bucket. When an IAM role with permissions to access the bucket is assigned, the user can list the bucket's contents.

The user must be permitted to switch to the role with permissions to list the bucket's content.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::$aws-account-id:role/ci-s3-editor"
        }
    ]
}

The ci-s3-editor role attaches the same policy that allows s3:ListJobs on the bucket.

The ci-s3-editor role must trust the user. Typically, role trust is established with a user group than individual users.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$aws-account-id:user/unprivileged"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Modify ~/.aws/config to create a new profile for ci-s3-editor role.

[profile s3access] 
role_arn = arn:aws:iam::$aws-account-id:role/ci-s3-editor 
source_profile = default

List the contents of the bucket

aws s3 ls s3://sayantam-hailstorm-ci/ --profile s3access

Without the --profile s3access, the ci-s3-editor role is not assumed, and the IAM user is denied access to the S3 resource.

Wrap Up

This was a quick tour of the fundamentals of authentication and authorization in AWS. Next up is AWS Cognito.