Getting Started with AWS (Part 9)

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

Introduction

In the last few articles of this series we’ve been looking at 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. We started by examining the features of the IAM Console and then described how you can create a friendly alias for your AWS account ID to make sure you haven’t generated any access keys for your AWS root account, 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, how you can implement multi-factor authentication (MFA) for adding an extra layer of protection to your AWS root account and IAM user accounts, and how you can use IAM policies to assign permissions for controlling access to AWS resources.

Understanding how to create and use policies is a key ingredient in helping to ensure that your AWS cloud environment is properly secured, and in the last article of this series we explained the difference between permissions and policies and described some of the default policies available in IAM for you to use. As you learned in the last article, most of the default policies can be used only for controlling access to specific AWS services and resources. For example, the AmazonEC2ReadOnlyAccess policy template can be used to provide read only access to Amazon EC2 via the AWS Management Console, and this policy is only useful if you are using the Amazon Elastic Compute Cloud (EC2) service offering of AWS.

While AWS provides you out of the box with more than 100 different default policy templates you can utilize, there may be times when you want to control access to your AWS services and resources in a more granular fashion than any of the default policies allow. In this article and the next one in this series we’ll look at several different ways you can create your own customized policies. But before we do this, let’s first look under the hood again to find out how policies are defined in IAM.

Understanding policy documents

In the previous article we examined the underlying policy document that defines what an IAM policy can do. In particular, we examined the details of the AmazonEC2ReadOnlyAccess, one of the many default policies available. To examine this policy, log on to the AWS console and open the IAM Management Console. Then select the Policies page on the left and click on the AmazonEC2ReadOnlyAccess policy from the list of policies displayed. The resulting Policy Details page looks like this:

Image
Figure 1: Details concerning the AmazonEC2ReportsAccess policy

The key thing we want to examine today is the script in the Policy Document section of this page. This script is written in a special formatting language called JSON which stands for JavaScript Object Notation, a lightweight text-only format for how data is stored and exchanged. JSON is based on a subset of the JavaScript programming language and is standardized as the JSON Data Interchange Standard ECMA-404 (see this link).

One way of understanding JSON is to compare it with XML (Extensible Markup Language) which like JSON is a text format for defining structured data and is also independent of the programming language being used for manipulating the data. For example, the XML snippet below defines a data structure called <users> that contains three <user> structures each of which has <first> and <last> name attributes:

<users>

<user>

<firstName>Bob</firstName>

<lastName>Smith</lastName>

</user>

<user>

<firstName>Mary</firstName>

<lastName>Jones</lastName>

</user>

<user>

<firstName>Don</firstName>

<lastName>Juan</lastName>

</user>

</users>

A similar data structure in JSON might look like this:

{

“users”: [

{

“firstName”: “Bob”,

“lastName”: “Smith”

}

{

“firstName”: “Mary”,

“lastName”: “Jones”

}

{

“firstName”: “Don”,

“lastName”: “Juan”

}

]

}

In the above JSON data structure we have an object with name “users” and an array of values, each of which consists of a name/value pair. An object in JSON begins and ends with curly braces and consists of one or more name:value pairs separated by commas. In the above example there are four objects:

{ “users”: […] }

{ “firstName”: “Bob”, “lastName”: “Smith” }

{ “firstName”: “Mary”, “lastName”: “Jones” }

{ “firstName”: “Don”, “lastName”: “Juan” }

The second, third and fourth objects each consist of two name:value pairs where the values are strings. In the first object, the value is an array as indicated by the square brackets and which contains one or more elements. In JSON, the value in a name:value pair can be either a string (which must be enclosed in double quotes), a number, TRUE, FALSE, NULL, an array, or another object. The name however in a name:value pair must always be a string enclosed in double quotes.

And that’s about it as far as the JSON syntax is concerned. JSON has objects, name:value pairs or elements, and arrays. Simple, isn’t it?

Now let’s examine the JSON in the policy document that underlies the AmazonEC2ReadOnlyAccess policy:

{

“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”: “*”

}

]

}

The above policy document includes five different kinds of elements:

Version – This element is required and is used to specify the version of the policy language being used and should always have the value “2012-10-17” as shown above.

Statement – This element is also required and contains an array of elements that define the kind of permissions the policy will grant or deny when the policy is attached to an IAM user or group.

Effect – This type of element defines whether access to the resource will be allowed or denied.

Action – This type of element describes the action(s) that the Effect element either allows or denies.

Resource – This type of element specifies the resource(s) that the Action and Effect elements are controlling access to.

There are other types of elements that a policy document can contain, but the above ones are the most common ones.

Now in simplified form the above policy document basically looks like this:

{ “Version”: “2012-10-17”, “Statement”: […] }

That’s the bare-bones structure that any valid IAM policy document must have. The “meat” of the policy is obviously in the array, and after adding some more detail our policy document now looks like this:

{ “Version”: “2012-10-17”, “Statement”: [object1, object2, object3, …] }

Each of the object items in the array for the Statement element must be in the following form:

{ “Effect”: effect, “Action”: action, “Resource”: resource }

Here effect can be either “Allow” or “Deny”, action can be either a string or an array of name:value pairs, and resource can be either a string or an array of name:value pairs. Let’s look at the first object in the Statement element of our policy document:

{

“Effect”: “Allow”,

“Action”: “ec2:Describe*”,

“Resource”: “*”

}

The above policy snippet allows the user or group to which the policy has been attached to describe (obtain information about) any and all information (see the asterisk wildcard symbol) relating to Amazon EC2 instances and environment. As an exercise, see if you can figure out what the remaining objects in the Statement array of our example policy document will do when the policy is applied to a user or group.

Additional resources

For more information on how JSON is used for defining IAM policies, see the AWS IAM Policy Reference.

For a basic overview of JSON and links to numerous other resources on the subject, see http://json.org.

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

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

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

Scroll to Top