Getting Started with AWS (Part 8)

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

Here’s a quick recap what we’ve learned so far in this short series of articles:

Part 1 described the free usage tier of Amazon Web Services (AWS) and how you can sign up for it so you can test drive AWS for 12 months.
Part 2 examined the various management and development tools provided by Amazon for creating and managing cloud resources on AWS.
Part 3 described some steps you can use to secure your AWS account in case your account becomes compromised.
Part 4 introduced the AWS Identity and Access Management (IAM), a web service that enables you to create and manage users and assign user permissions for your AWS cloud environment.
Part 5 described the features of the IAM Console and how to create a friendly alias for your AWS account ID to make sure you haven’t generated any access keys for your AWS root account.
Part 6 demonstrated how you can create a new user that has administrator privileges so you can use this user instead of your root account for managing your AWS environment.
Part 7 examined how to implement multi-factor authentication (MFA) for adding an extra layer of protection to your AWS root account and IAM user accounts and discussed the advantages and disadvantages of using MFA for protecting AWS accounts–especially your root account.

In this next part of the series we are going to begin digging into the subject of how you can assign permissions for controlling access to AWS resources by attaching IAM policies.

Policies vs permissions

We actually previously introduced the subject of policies indirectly in Part 6 of this series when we created a new IAM group called Admins for our AWS Free Tier test environment. If you recall, one of the pages of the Create New Group Wizard was called Set Permissions and it looked like this:

Figure 1: The Set Permissions page of the Create New Group Wizard

As you can see from the above screenshot, permissions are assigned to an IAM group (or user or role for that matter) by attaching a policy to the group. Logically speaking, a policy is simply a container for permissions, similar in many ways to an access control list (ACL) on the Microsoft Windows platform. In terms of its under the hood implementation in AWS, a policy is basically just a text file that contains some JSON (JavaScript Object Notation) scripting that defines the actions that can be performed, the resources on which the actions can be acted upon, and the effect (allow or deny) that occurs when the actor (e.g. user) requests to perform the action upon the resource. Figure 2 which is also reproduced from the earlier Part 6 article shows the JSON script that underlies the Administrator Access policy template:

Figure 2: The JSON script that underlies the Administrator Access policy template

Amazon recently made a few changes to the IAM console that affect how you create, select and apply policies to users, groups or roles in your AWS environment. For example, Step 2 Permissions of the Create New Group Wizard is now Step 2 Policy, and with this change you no longer have the option of creating a custom policy within the Create New Group Wizard. Instead, you can now only select one of the default IAM policies and apply it to the group you are creating. In addition, you can only select two policies to attach to the group as illustrated by the next figure:

Figure 3: The new Attach Policy page of the Create New Group Wizard

The default policies

Amazon also recently added a new Policies page to the IAM console. As shown in Figure 4 below, the Policies page is the central place in IAM where you can create, manage and apply policies to users, groups and roles in your environment.

Figure 4: The new Policies page in the IAM console

Why are there over a hundred default policy templates available for you to use in your AWS environment? While that might seem to be a large number of policies, it’s actually quite simple: it’s mainly because there are so many different kinds of service offerings in the AWS cloud. As an example, consider Amazon EC2, their web service that offers resizable cloud hosting services to make web-scale computing easier for developers. As you can see from the above figure, there are four default policies you can use to control the kind of access that users, groups or roles can have for this service:

AmazonEC2FullAccess – Provides full access to Amazon EC2 via the AWS Management Console
AmazonEC2ReadOnlyAccess – Provides read only access to Amazon EC2 via the AWS Management Console
AmazonEC2ReportsAccess – Provides full access to all Amazon EC2 reports via the AWS Management Console
AmazonEC2RoleforDataPipelineRole – Default policy for the Amazon EC2 Role for Data Pipeline service role

The descriptions of the policies in the bullet list above can be found by clicking on any of these policies on the Policies page of the IAM Console. For example, the next figure shows details concerning the AmazonEC2ReadOnlyAccess policy:

Figure 5: Details concerning the AmazonEC2ReportsAccess policy

Notice that the Policy Document section is read-only and doesn’t allow you to scroll through the JSON to study the fine details of the policy. You can get around this limitation by going back to the main Policies page (Figure 4) and clicking the Create Policy button which opens the Create Policy wizard:

Figure 6: The Create Policy wizard

Now click the Select button under Copy an AWS Managed Policy. You’ll be taken to a page that shows a list of available policies in alphabetical order. Instead of scrolling, type the name of the policy you want to copy (which in this example is the AmazonEC2ReadOnlyAccessm policy) into the Search Policies box, and the policy you want will be displayed:

Figure 7: Selecting the AmazonEC2ReadOnlyAccess policy to copy it.

Clicking the Select button shown above takes you to the Review Policy page, which shows the JSON policy document again but this time in a form you can click and select so you can copy it to the clipboard:

Figure 8: Copying the JSON of the policy document to the clipboard.

Here’s what the JSON of the policy document for the AmazonEC2ReadOnlyAccess policy looks like in full:

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

  "Statement": [

      "Effect": "Allow",

      "Action": "ec2:Describe*",

      "Resource": "*"

},

      "Effect": "Allow",

      "Action": "elasticloadbalancing:Describe*",

      "Resource": "*"

},

      "Effect": "Allow",

      "Action": [

        "cloudwatch:ListMetrics",

        "cloudwatch:GetMetricStatistics",

        "cloudwatch:Describe*"

],

      "Resource": "*"

},

      "Effect": "Allow",

      "Action": "autoscaling:Describe*",

      "Resource": "*"

Even without needing to know the full details of the syntax, it’s fairly obvious what this policy does. But since we’ll be creating a custom policy in our next article, we’ll need to understand the syntax a bit. But we’ll leave this for our next article in this series.

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