The following JSON document is an example that was created to describe some of the key features of IAM policy documents:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "MyGeneralEC2Statement"
            "Effect": "Allow",
            "Action": "ec2:*",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetUser"
            ],
            "Resource": "arn:aws:iam::123456789012:user/TestUser"
        },
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "*",
            "Condition": {
                "Bool": {
                    "aws:MultiFactorAuthPresent": "true"
                }
            }
        }
    ]
}

This policy has examples of some of the most common features of IAM policies. First, we have the Version key, which specifies the version of the policy language that is being used. The best practice is to use the latest version, which is currently 2012-10-17, and not much thought needs to be given to it beyond that.

Next, we have the Statement key, which is a list of JSON objects known as statements. Statements are the individual declarations of permissions and the settings relating to them. A statement can consist of the Sid, Effect, Action, NotAction, Principal, Resource, and Condition keys.

Sid is an optional field and is a string of your choice that is provided to assist in differentiating between the different statements in a policy. It doesn't need to be supplied, but if it is, it basically just makes understanding the policy easier for a reader. In the preceding policy, the MyGeneralEC2Statement Sid is meant to convey that the statement is a general statement for the EC2 service.

An Effect key is a required field that can be set to either Allow or Deny, and it declares whether the listed AWS permissions (under Action or NotAction) are explicitly allowed or explicitly denied. All of the statements in the preceding example policy explicitly allow the associated permissions.

One key of either Action or NotAction is required, and it contains a set of AWS permissions. Almost every time, you will see Action being used instead of NotAction. The first statement in the previous example policy explicitly allows the ec2:* action, which uses the IAM policy wildcard character (*).

Permissions are set up in the format of [AWS Service]:[Permission], so the ec2:* permission specifies every single permission relating to the AWS EC2 service (such as ec2:RunInstances and ec2:CopyImage). The wildcard character can be used in various places in an IAM policy, such as in the following permission: ec2:Describe*. That would represent every single EC2 permission that begins with Describe (such as ec2:DescribeInstances and ec2:DescribeImages). NotAction is a little bit more complicated, but basically, they are the opposite of Action. This means that NotAction ec2:Modify* would represent every single API call for all AWS services, except for EC2 permissions that begin with Modify (such as ec2:ModifyVolume and ec2:ModifyHosts).

The Principal key applies to different kinds of IAM policies, outside of what we have looked at so far (such as the assume role policy document in the previous section). It represents the resource that the statement is meant to apply to, but it is automatically implied in permission policies for your users, roles, and groups, so we are going to skip over it for now.

The Resource key is a required field and is a list of what AWS resources the specified permissions under the Action/NotAction section apply to. This value is often just specified as the wildcard character, which represents any AWS resource, but it is a best practice for most AWS permissions to be locked down to the required resources that they must be used on. In the second statement, we have listed in our example policy, we have the resource listed as arn:aws:iam::123456789012:user/TestUser, which is the ARN of a user in the account with the 123456789012 account ID and the TestUser username. This means that we are only allowed (the effect) to perform the iam:GetUser API call (the action) on a user in the account with the 123456789012 ID and the TestUser username (the resource). Note that although the account ID is listed in the resource, many API calls cannot be used on a resource belonging to a different AWS account from the user/role who is making the call, even if a wildcard was present, rather than the account ID.

The Condition key is an optional field that indicates under what conditions the specifications of the statement apply. In the third statement of our preceding example, we have the Bool condition (Boolean—in other words, true/false) known as aws:MultiFactorAuthPresent set to true. What this means is that for this statement to apply (allowing the sts:AssumeRole permission on any resource), the user/role must be multi-factor authenticated with AWS; otherwise, that permission is not allowed. There are many other conditions that can be specified, such as requiring a certain source IP address for any API calls, requiring the API call to be made within a certain timeframe, and many more (see https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html).