Getting Started with AWS (Part 10)

If you would like to read the other parts in this article series please go to:

Introduction

In the previous article in this series we looked at how policy documents are used to define the policies you can use to control access to the resources in your AWS environment. In this article we’ll walk through how you can create custom policies for more granular control over the resources in your AWS environment.

Creating custom policies

The Policies page of the AWS Identity and Access Management console is where you can create your own custom policies for controlling access to the resources in your AWS environment. As we saw in the previous article, when you select Policies on the left side of the IAM console you’ll see a list showing all of the policies available in your environment. Initially, this list will be populated only with the default policies that come built-in with AWS. To create a custom policy of your own making, start by clicking the Create Policy button as shown here:

ImageFigure 1: Creating a custom policy using the IAM console.

As the next screenshot shows, the Create Policy page indicates that you have three different ways for creating custom policies in IAM:

  • Copy an AWS Managed Policy – This method allows you to use an existing policy as a kind of template for starting to create a new policy that fits your needs.
  • Policy Generator – This is a wizard-like tool that allows you to create a custom policy based on the services the policy will control access to and the actions that should be allowed by users or groups to which the policy is attached.
  • Create Your Own Policy – This method lets you create a new policy from scratch by typing a series of JSON statements.

Image
Figure 2: Three ways for creating a custom policy with the IAM console.

Let’s examine each of these three approaches in turn beginning with the first one, the Copy an AWS Managed Policy option. But before we do this, let’s briefly clarify something concerning the different kinds of policies available in IAM.

Types of policies

IAM provides several different types of policies you can choose from for controlling access to your AWS environment. These policy types include:

  • Managed policies – This type of policy can be attached to one or more users, groups, and/or roles in your environment. Managed policies themselves can be further categorized as either default policies (also known as AWS managed policies) or custom policies (also called customer managed policies).
  • Inline policies – This type can also apply to users, groups, and/or roles, but the difference is that an inline policy is directly embedded into the user, group or role to which it applies. So while a single managed policy could be attached for example to three groups, five users and two roles, an inline policy only applies to the single user, group or role in which the policy is embedded. An example of an inline policy is the one we created when we set permissions for the new group called Admins that we created in Part 6 of this series.
  • Resource-based policies – This approach involves assigning permissions to a resource (like Amazon S3 buckets) instead of to the user, group or role that needs to access (or be denied access to) the resource. We’ll examine this topic in a future article on this site.

Now let’s look at how you can use the Copy an AWS Managed Policy option to create your own custom policy.

Method 1: Copy an AWS Managed Policy

The first method for creating a new policy is to use an existing policy as a kind of template for creating the custom policy that fits your needs. To begin this process, click the Copy an AWS Managed Policy button shown previously in Figure 1. Doing this displays the Copy an AWS Managed Policy page shown here:

Image
Figure 3: Step 1 of creating a new policy using the Copy an AWS Managed Policy option.

Let’s use the AdministratorAccess default policy as the starting point for creating a new custom policy that will allow complete access to everything in our AWS environment except for anything relating to Amazon Elastic Compute Cloud (EC2).

Clicking the Select button beside this policy opens the Review Policy page shown here:

Image
Figure 4: Step 2 of creating a new policy using the Copy an AWS Managed Policy option.

As you can see above, IAM automatically appends a date/time string to the policy you selected and suggests this as a name for your new policy. We’ll rename our policy and modify the description to indicate the intended nature of our new policy. Then we’ll add the following JSON to the policy document to deny access to EC2 resources for an users, groups or roles to which the policy will be attached:

{

“Action”: “ec2:*”,

“Effect”: “Deny”,

“Resource”: “*”

}

Then we’ll click the Validate Policy button at the bottom of the Review Policy page to make sure we have the JSON syntax correct in the policy document of our new policy. When we do this, we get an error:

Image
Figure 5: Step 3 of creating a new policy using the Copy an AWS Managed Policy option.

What went wrong? There’s an extraneous comma at the end of line 13 and once we delete it and click Validate Policy again, everything is OK:

Image
Figure 6: Step 4 of creating a new policy using the Copy an AWS Managed Policy option.

Clicking the Create Policy button closes the wizard and returns us to the Policies page where our new policy is now listed as the second policy in the list of managed policies displayed on the page:

Image
Figure 7: Attaching the newly created policy.

Why is there no orange cube beside this new policy? Because it’s a customer managed (i.e. custom) policy and not an AWS managed (i.e. default) policy.

Let’s now see whether our new policy works. To do this, we’ll attach the policy to a group called Admins_no_EC2 that we created. A user named Mary_Jones belongs to this group, and if we then log on to the AWS Management Console with this user, we shouldn’t be able to do anything with the EC2 service.

So we’ll start by selecting our new policy from the list of managed policies. Then we’ll click the Policies Action button and select Attach (see the previous screenshot) which opens the Attached Policy page here:

Image
Figure 8: Selecting a group to attach the new policy to.

We select the Admins_no_EC2 group as shown above and click the Attach Policy button. Once we’ve done this, we can switch to the Groups page in the IAM console where we can see that we now have two new policies defined in our environment: the Admins inline policy we created earlier in Part 6 and the Admins_no_EC2 customer managed policy which we have just created here:

Image
Figure 9: The new policy has been attached to the group.

Now we’ll log off as Bob_Smith (a member of our Admins group) and log on as Mary_Jones (a member of our Admins_no_EC2) group. Now when we click on the EC2 icon on the console home page, we’re taken to the EC2 Dashboard page where we can see that Mary is not authorized to view any information or perform any tasks relating to EC2:

Image
Figure 10: The policy does what was intended.

We’ll look at the remaining two methods for creating custom policies in the next article of this series.

If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top