Understanding the difference between policy types

We looked into different policies when discussing users, groups, and roles in the previous chapter. So now, we will dive deeper into these policies and discuss the various different types of policies and what they look like.

Policies are associated with users, groups, roles, or resources and define who or what can or can’t access AWS resources. You may already be familiar with some policy types, but AWS supports a number of different types of policies, including the following:

• Identity-based policies
• Resource-based policies
• Permissions boundaries
• Access Control Lists (ACLs)
• Organization Service Control Policies (SCPs)

We will discuss these policies one by one in the following subsections.

Identity-based policies

If you have been using AWS for any length of time, then this type of policy is probably the most familiar to you. You can attach these policies to identities that have been created within the IAM service and they essentially associate specific permissions associated with the identity. For example, if a group had a policy allowing full Amazon Simple Storage Service (S3) access, then that is an identity-based policy as users of the group would be granted permissions based on the policies bound to that group.

Identity-based policies can either be AWS-managed, customer-managed, or in-line policies, which we will discuss now:

• AWS-managed policies: These are predefined policies that can be found within IAM and are available to use without having to create your own. The following screenshot shows a sample of the EC2-managed policies that are available:

As you can see, there is a wide range of policies for each service with varying levels of access. At the time of writing this book, there are over 480 AWS-managed policies to choose from. They can all be accessed by selecting Policies from within the IAM management console.

• Customer-managed policies: These are policies that have been customized by us as customers. There might not be an AWS-managed policy that is correct; as a result, you may need to either copy and customize an existing managed policy or create your own from scratch by using the visual editor or writing it using JavaScript Object Notation (JSON) format. Customer-managed identity-based policies give you far more granular control over how you want to manage access for identities than AWS-managed policies.
• In-line policies: These are different from both AWS- and customer-managed policies in the sense that in-line policies are embedded directly into the identity object; for example, customer-managed policies are stored in IAM as separate objects and can then be assigned to multiple identities, such as groups, roles, and users. In-line policies are not stored as separate objects; they only exist within the identity that they are created—users or roles.  

As a general rule, it’s a best practice to use managed policies over in-line policies where possible as you have a clear view of managed policies within IAM, whereas in-line policies are embedded into identities and are not as visible. 

Resource-based policies

These are essentially in-line policies, but instead of being attached to an identity object, they are attached to resources themselves. For example, one of the most frequently used resource-based policies is Amazon S3 bucket policies.

As these policies are not attached to an identity, there needs to be a parameter within the policy that defines a principal so that AWS knows who or what these permissions apply to. This principal relates to an identity and can either reside in the same AWS account or in a different account. We will discuss principals later in this chapter when we look at the structure of policies.

Permissions boundaries

These are policies that govern the maximum permissions that an identity-based policy can associate with any user or role; however, the permissions boundary policy itself does not apply permissions to users or roles. It simply restricts those given by the identity-based policy.

To create a permissions boundary, you can perform the following steps:

1. From within the IAM management console, select your user or role. In this example, we have selected a user who has been assigned permissions from a group, AmazonS3FullAccess (as per the best practices), giving full access to S3. However, if you wanted to restrict this level of access to S3 either temporarily or permanently for this particular user, you could set a permissions boundary:

1. Select the arrow next to Permissions boundary (not set). This will open a drop-down menu:

1. Select Set Boundary. This will then take you to a screen showing all the managed policies (both AWS- and customer-managed). From here, you can select a new policy to act as the maximum boundary—for example, AmazonS3ReadOnlyAccess. Once you have selected your policy, click Set boundary:

1. This new boundary will restrict that user's permissions to S3 as read-only based on the associated managed policy of that boundary. This is despite the user being a member of a group that has access to AmazonS3FullAccess.

If you want to explore permissions boundaries in greater depth and understand how they are evaluated against all other permissions, please refer to https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html.

Access control lists

Firstly, do not confuse ACLs with network access control lists (NACLs), which are used to control network traffic (discussed later in this chapter). ACLs are used in Amazon S3 and act much like resource-based policies, as these ACLs can be attached to buckets. They can also be attached to S3 objects, whereas bucket policies (discussed later in this chapter) can’t. However, ACLs are used only to control cross-account access from a different AWS account or public access.

When configuring your ACLs, you have a number of options as to who can access the object or bucket via an ACL:

• Access for other AWS Accounts: Using this option, you can enter the email address of the account owner or the canonical ID of the AWS account.
• Public Access: This is a pre-configured S3 group created by AWS and allows anyone with internet access to have access to your object. This should be used with extreme caution and should only be used if necessary. Ensure that no sensitive or confidential data is stored within an object or bucket that has public access.
• S3 Log Delivery Group: Again, this is another pre-configured S3 group created by AWS. This option allows write permission to the bucket for S3 server access logging. If this logging is configured, these logs can be useful from a security and audit point of view.

To view these options and the permission level, do the following:

1. From the AWS management console, select S3:

1. Select the bucket that you would like to configure permissions for.
2. Select the Permissions tab:

1. Select the Access Control List option:

1. You will then see that there are minimal permissions that can be assigned for each of the three options, in addition to the bucket owner, as shown:

In fact, these are the only policies that are not written in JSON format. The permissions are as follows:

In this section, we looked at how we can use ACLs to control cross-account access from a different AWS account, as well as public access or access for server-access logging on a per bucket basis.

Organization SCPs

These are policies that are used by AWS organizations, which are used to manage multiple AWS accounts. Organizations can be used to allow you to centrally manage your AWS accounts in a hierarchical structure, and grouping can be done through Organization Units (OUs). SCPs act in a similar manner to permissions boundaries within identity objects. They set the maximum permission level that can be given to members of an associated AWS account or OU. They restrict what level both identity-based and resource-based policies can grant permission for both users and roles, but the SCPs do not themselves grant any permissions.

For example, the following SCP would deny anyone within the AWS account associated with the SCP from deleting VPC Flow Logs, even if they had access via an identity-based policy:

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Deny",
     "Action": [
       "ec2:DeleteFlowLogs",
       "logs:DeleteLogGroup",
       "logs:DeleteLogStream"
     ],
     "Resource": "*"
   }
 ]
}

With this, we come to the end of the section covering the various access policies. Remember that since these policies determine who or what can or can’t access AWS resources, they are very important to understand in order to ensure the security of your environment is maintained. The syntax of this policy, as well as other JSON policies used (for example, those within IAM) are covered in the next section. So, let's take a look at that next.