AWS IAM Policies Made Easy for Beginners

In this write-up, I will take a walkthrough of the AWS IAM Policies, but simplifying the topic to a beginner level is the central point of interest of this write-up and this will take us to “What is AWS IAM”?

What is AWS IAM?

IAM is an acronym for Identity and Access Management.

To keep it simple, according to the AWS official documentation “AWS Identity and Access Management (IAM) provides fine-grained access control across all of AWS. With IAM, you can specify who can access which services and resources, and under which conditions. With IAM policies, you manage permissions to your workforce and systems to ensure least-privilege permissions.”

Regardless of the technique, you employ to carry out the operation, IAM policies define permissions for an action. For instance, if a policy permits the GetUserPolicy action, a user with that policy can retrieve the specified inline policy document that is embedded in the specified IAM user.

With AWS IAM, you have the option to grant console or programmatic access when you create an IAM user. The IAM user can log into the console with a user name and password if console access is granted. Alternatively, the user can use access keys to interact with the CLI or API if programmatic access is granted.

Type of AWS IAM Policies

AWS IAM can be classified into 6 types. For the purpose of this write-up, we will only look at the 4 most prominent types. You can review this AWS documentation to learn about the other 2 types.

The 4 types we will discuss briefly are:

1. Identity-based policies — They’re attached to Users, User Groups and Roles within IAM. Basically, this policy type is attached to any entity that depends on the identity.
2. Resource-based Policies — These policies are associated with the AWS resources. They’re attached as inline resource policies i.e. instead of defining policies for identity, they’re attached inline to resources. For instance, Amazon S3 buckets can have resource-based policies attached to them. You can learn more about Identity-based and Resource-based policies by clicking here.
3. Permission Boundaries — This type of policy can be associated with a role or user but they don’t actually grant permission themselves instead they define the maximum level of permission that can be granted to a user or entity.
4. Organization Service Control Policies (SCPs) — This is similar to permission boundaries in the sense that they don’t grant the actual permission. They’re associated with the AWS Organization Unit (OU). When working with the AWS Organization, they govern the maximum permission to the members of the organization account. Learn more about SCPs.

Analyzing the AWS JSON Policy Structure

IAM Policies are written in JSON document format. JSON is an acronym for JavaScript Object Notation. When defining the AWS IAM Policies JSON document, the syntax is the same for almost all the IAM Policy types but you might use parameters that are slightly different depending on the resources you are working with.

Below is the output of an IAM JSON Policy statement that prevents users from deleting and getting objects from the S3 Bucket

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1658851085578",
            "Action": [
                "s3:DeleteBucket",
                "s3:GetObject"
            ],
            "Effect": "Deny",
            "Resource": "arn:aws:s3:::iam-policy-bucket1"
        }
    ]
}

Now, let’s understand what each component of the JSON policy statement above means:

1. “Version”: “2012–10–17” — Specifies the policy language version and the language syntax used.
2. Statement — Defines the main element of the policy
3. Sub-elements — In some policy statements, you may need to define the sub-element. Sub-element identifies the level of access granted or denied and to which resource.
4. Statement id (Sid) — An optional parameter that lets set a unique identifier within the statement. You can have more than one Sid in AWS Policy Statement.
5. Effect — This can be set to either allow or deny. By default all
   IAM policies are set to deny. The effect either grants or restrict
   access to the “Action” defined in the “Statement”. Note: the deny policy always takes precedence over allow.
6. Principal/NotPrincipal — This specifies the principal who is granted or denied access to a resource. Sometimes, you may see it as NotPrincipal which is used to specify the IAM user, federated user, IAM role, AWS account, AWS service, or other principal that is not allowed or denied access to a resource.
7. Action — Action that will either be allowed or denied, depending on the value entered for the Effect parameter.
   NotAction — Lists a limited set of “Actions” that should not match.
8. Resource — This specifies the actual resource you wish the “Action” and “Effect” to be applied to using ARNs (Amazon Resource Names) such as arn:partition:service:region:account-id:resource.
9. NotResource — Can be used to explicitly match all other resources except those specified.
10. Condition — This is an optional element that allows you to control when the policy permission will be effective based on some set criteria. It is made of a condition and a key-value pair.
11. SourceIPAddress — Specifies the IP source IP Address for your resources.

Creating an IAM Policy Statement

IAM Policies can be created using any of the below 3 methods:

1. Copying an Existing AWS Managed Policy — This simply means replicating a policy statement already defined by AWS and modifying it to fit your purpose
2. Using a Policy Generator — The AWS Policy Generator is a tool that enables you to create policies that control access to Amazon Web Services (AWS) products and resources.
3. Creating Your Own Policy from scratch — This can be achieved in two ways; either you write the policy JSON document by yourself or you replicate it from the AWS visual editor. This is similar to creating IAM Policy from an existing AWS Managed Policy template.

To learn how to create AWS IAM Policies using any of the methods stated above, take a look at this short video clip.

Follow AWS Cloud Security User Group — West Africa on Twitter