IAM Roles – Determining an Authentication and Access Control Strategy for Complex Organizations – SAP-C02 Study Guide

IAM Roles

An IAM role is an identity that possesses specific permissions. It is like an IAM user in which it provides access to AWS resources and defines what the user or application assuming that role can do on AWS. It is different from an IAM user in that a role is not associated with a single individual or application but can be assumed by multiple entities. IAM roles are used to provide temporary credentials to entities (individuals, AWS services, or applications).

Important Note

An IAM user or role cannot span multiple AWS accounts. The Leveraging Access Delegation section will cover how cross-account access (accessing resources in AWS account A from AWS account B) can be granted.

IAM Policies

An IAM policy is an object that allows access control on AWS. It can be assigned either to an IAM identity (user, user group, or role) or to an AWS resource. When access to an AWS resource is requested, IAM will evaluate the permissions defined by all the policies entering the scope of that request and based on their intersection, decide whether access is allowed or denied. IAM supports multiple types of policies: identity-based policies, resource-based policies, permissions boundaries, organizations’ service control policies (SCPs), access control lists (ACLs), and session policies. You will explore these in the following sections.

Identity-Based Policies

Identity-based policies are JavaScript Object Notation (JSON) policy documents that are attached to IAM identities (users, user groups, or roles). They control what actions an IAM identity (user, user group, or role) can perform on which AWS resources and under which conditions. They are further subdivided into the following categories:

Managed policies: Managed policies are named policies and can be assigned to any number of IAM identities. They can be of two sorts, as outlined here:
1. AWS-managed policies: Policies created and managed by AWS
1. Customer-managed policies: Policies created and managed by you
Inline policies: Inline policies are permissions directly attached to a single IAM identity. Their life cycle is the same as that identity’s life cycle.

Here is an example of an identity-based policy that gives read-only access to all Simple Storage Service (S3) objects on its AWS account:

{
  “Version”: “2012-10-17”,
  “Statement”: [
    {
      “Effect”: “Allow”,
      “Action”: [
        “s3:Get*”,
        “s3:List*”
      ],
      “Resource”: “*”
    }
  ]
}

Note

Remember that an IAM identity has by default no permissions at all on AWS. You must assign one or more identity-based policies for it to be able to do something on AWS.

Resource-Based Policies

Resource-based policies are JSON policy documents that are attached to AWS resources. They control what actions can be performed on the attached resource(s) by which principal (user or role) under which conditions. As opposed to identity-based policies, resource-based policies are always inline policies.

Here is an example of a resource-based policy providing permissions to any principal (user or role) in the account to get any object from the S3 bucket identified by the Resource attribute:

{
  “Version”: “2012-10-17”,
  “Id”: “Policy123456789”,
  “Statement”: [
    {
      “Sid”: “”,
      “Action”: [
        “s3:GetObject”
      ],
      “Effect”: “Allow”,
      “Resource”: “arn:aws:s3:::my-bucket/*”,
      “Principal”: “*”
    }
  ]
}

Note

Remember that resource-based policies provide an opportunity to further protect your AWS resources by limiting not just what actions can be performed but also the IAM entities allowed to perform them.