User authentication and authorization are core features of Amazon Web Services (AWS). Together, these processes determine whether a principal can access AWS resources. A principal in this sense refers to a person or an application capable of requesting an action to be carried out on an AWS resource.

Authentication means signing in a principal to AWS using their credentials (such as username and password). On the other hand, authorization validates whether a principal is allowed to complete their request.

The AWS service responsible for authentication and authorization is the Identity and Access Management (IAM) web service. In other words, IAM is a web service that helps you securely control access to AWS resources. This control over AWS resources in IAM is achieved via the mechanism of JSON documents known as ‘policies’. When attached to an identity or resource, these policies define their permissions.

In the rest of this article, you will learn the following about IAM policies and permissions:

• Meaning and function of policies

• Types of policies

• Structure of a JSON policy document

What are IAM Policies and Permissions?

In AWS, a policy is a JSON document object that is associated with an identity or resource to define its permissions. An identity could refer to a user, group of users, or roles, while an AWS resource could be something like an Amazon EC2 instance or an Amazon S3 bucket. Whenever an IAM principal makes a request, AWS evaluates the related policies to decide whether the request is granted or not. The permissions specified in the policies determine if the request is allowed or denied.

Before moving further, note that IAM policies do not affect the method used to act on a resource. Once a certain action is approved, any possible method can be used to carry it out.

Types of Policies

Listed in order from the most frequently used to the least frequently used, the following are the six types of policies used in AWS:

• Identity-based policies: These are policies that you attach to an identity. Identity-based policies control what operations an identity can perform, on which resources, and the necessary conditions. Identity-based policies are further divided into two: managed policies and inline policies.

  • Managed policies- They are standalone policies that you can assign to several users, groups, and roles in your AWS account. Managed policies are further sub-divided into two:

    • AWS managed policies: AWS creates and manages these policies on your behalf.

    • Customer-managed policies: These are created and managed by you- the customer, in your AWS account.

  • Inline policies- Unlike managed policies, you add inline policies directly to a single user, group, or role; there is a strict one-to-one association between a policy and an identity, and the policy is often deleted when you delete the identity.

• Resource-based policies: Resource-based policies are the kind of policies that you attach to a resource, such as an Amazon EC2 instance. These policies restrict the actions a principal can carry out on the resource and define the requisite conditions. Resource-based policies are usually inline policies (i.e. one policy for one resource).

• IAM Permissions boundaries: In a permissions boundary, you limit the maximum permissions that an identity-based policy can give to an IAM entity. By setting the permissions boundary, the entity is only allowed to perform the actions permitted by both its identity-based policies and its permissions boundary. Permissions boundary is an advanced feature that does not affect resource-based policies.

• Service control policies (SCPs): Service control policies are used in AWS Organizations to set the maximum permissions for an organization or organizational unit (OU). AWS Organizations is an AWS service that helps you group and manage all the AWS accounts that your business owns. By applying SCP to any member account, you limit permissions for entities in the account, including the account root user.

• Access control lists (ACLs): Access control lists are the only policy type that is not JSON documents. They are service policies that allow you to choose which principals in another account can access a resource. You cannot use ACLs to control access for a principal within the same account.

• Session policies: Session policies are advanced policies that are used when you create a temporary session for a role or federated user. The permissions for a session are the intersection of the session policies and any other policies-such as identity-based policies- used to create the session.

Format of a JSON Policy Document

The main elements of a JSON policy document are:

• (Optional) General policy information is at the top.

• One or more individual statements.

A policy statement may contain some or all of these sub-elements:

• Version- Indicates the version of the policy language used.

• Sid- (Optional) Statement ID to distinguish between different statements.

• Effect- ‘Allow’ or ‘Deny’.

• Principal (Optional, depends on the policy type)

• Action- List of actions permitted by the policy.

• Resource (may be included depending on policy type)

• Condition (Optionally specified)

Each policy statement is for single permission. You can use multiple statements in a single policy to specify multiple permissions for an entity. You can also apply multiple approaches to a single request.

An example of a JSON policy document with a single statement is shown below.

{

  "Version": "2012-10-17",

  "Statement": [{

    "Sid": "3",

    "Effect": "Deny",

    "Principal": {"AWS": ["arn:aws:iam::account-id:root"]},

    "Action": "s3:*",

    "Resource": [

      "arn:aws:s3:::mybucket",

      "arn:aws:s3:::mybucket/*"

    ]

  }]

}

Another example of a JSON policy document is shown below. The document contains three statements, each of which defines a separate set of permissions within a single account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "FirstPermission",
      "Effect": "Allow",
      "Action": ["iam:KeepPassword"],
      "Resource": "*"
    },
    {
      "Sid": "SecondPermission",
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*"
    },
    {
      "Sid": "ThirdPermission",
      "Effect": "Allow",
      "Action": [
        "s3:List*",
        "s3:Get*"
      ],
      "Resource": [
        "arn:aws:s3:::confidential-data",
        "arn:aws:s3:::confidential-data/*"
      ],
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    }
  ]
}

Conclusion

In this article, we discussed how AWS controls access to resources via the framework of IAM policies and permissions. You have learned that policies contain permission statements that grant or deny access to AWS resources. Furthermore, you saw the six different types of policies and their use cases, as also the general structure of a JSON policy document.

Moreover, we have only scratched the surface of an extensive and interesting aspect of AWS. For more detailed information on policies and permissions in AWS, kindly check the official AWS documentation, here.