AWS Made Easy | IAM Policy
Tags: aws, cloud
Published: 2021-03-11 19:36:08

---
title: AWS Made Easy | IAM Policy
published: true
date: 2021-03-03 05:01:40 UTC
tags: aws,aws,cloud
canonical_url: https://www.archerimagine.com/articles/aws/aws-iam-policy.html
---

![AWS Made Easy | IAM Policy](https://www.archerimagine.com/images/aws/IAM/02-IAM-Policy.png "AWS Made Easy | IAM Policy")

## IAM Policy[¶](#iam-policy "Permanent link")

A document which provides the details of the permission granted to access any AWS resources is called an **IAM Policy.** The default policy applied to all AWS users is **non explicit deny**.

The IAM Policy takes effect as soon it is attached to a user or group, there is no delay in its application. The User & Groups can have more than 1 policy attached at any given time. Roles are utilized because we cannot attach policy directly to AWS resources.

### IAM Policy Document[¶](#iam-policy-document "Permanent link")

How does an IAM Policy look like.

```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

```

The above is an example of an IAM Policy

If we observe closely, these are the various important points to note about the IAM Policy.

- Statement
  - Each IAM policy is composed of **statements**. Policy can have one or more statements. In the above example, there is only 1 statement, composed of
  - Effect
    - It tells if the impact is allowed or deny. It takes these 2 values. In the above example, it is **Allow** for all.
  - Action
    - What type of action is allowed or denied. We can drill it down to single API also, which we will see later. In the above example, it is allowing all actions.
  - Resource
    - Which resource are being accessed using the policy. Like in case of S3, it can mention the resource is a S3 bucket, not the full S3. In the above example, all the resources are being granted access.

### Explicit Allow & Explicit deny[¶](#explicit-allow-explicit-deny "Permanent link")

When granting access explicitly we have 2 categories of IAM Policy

- Explicit Allow
- Explicit Deny

When a user has both explicit allow and explicit deny, then the explicit deny always take precedence. In all cases just remember deny is the best way.

- Example of explicit allow

```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

```

- Example of explicit deny

```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

```

## IAM Policy Templates[¶](#iam-policy-templates "Permanent link")

We can have an IAM policy in two ways.

- Pre-Built Policy
- Custom Policy

### Pre-Built Policy[¶](#pre-built-policy "Permanent link")

- These are the policies provided by AWS to all the users. We can just pick and use which ever we like.
- These policies are identified with an Amazon logo just next to them. ![AWS Made Easy | AWS managed IAM Policy](https://www.archerimagine.com/images/aws/IAM/02-aws-managed-policy.png "AWS Made Easy | AWS managed IAM Policy")
  - Most commonly used pre-build polices are 
    - Administrator Access
    - Power User Access
    - Read-Only Access

### Administrator Access[¶](#administrator-access "Permanent link")

Administrator Access: Full Access to all AWS resources.

```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

```

### Power User Access[¶](#power-user-access "Permanent link")

Admin Access, except it does not allow user-group management.

```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "NotAction": [
                "iam:*",
                "organizations:*",
                "account:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "iam:DeleteServiceLinkedRole",
                "iam:ListRoles",
                "organizations:DescribeOrganization",
                "account:ListRegions"
            ],
            "Resource": "*"
        }
    ]
}

```

### Read-Only Access[¶](#read-only-access "Permanent link")

Only View AWS resources. This policy is very big, please search for it in AWS. - The AWS managed policies cannot be edited, they are read only.

### Custom Policy[¶](#custom-policy "Permanent link")

- Some time the requirements of a policy cannot be fulfilled from an AWS managed policy. We have to use a custom policy in those cases. 
- We can import the pre-built policy into our own, and then modify them.

## Custom IAM Policy Generation[¶](#custom-iam-policy-generation "Permanent link")

In addition to AWS provided policy, user can also create custom policy. We have 2 methods to create custom policy.

- Visual Editor
- JSON Editor

### Visual Editor[¶](#visual-editor "Permanent link")

The are 4 selections, we have to do for creating a policy, as shown below.

![AWS Made Easy | AWS create IAM Policy](https://www.archerimagine.com/images/aws/IAM/02-create-policy.png "AWS Made Easy | AWS create IAM Policy")

- Service
  - Choose a service like, IAM, S3, EC2 on which the policy is applicable.
- Actions
  - Based on the service selected, we can choose the Actions, which can be associated with it.
  - Primarily the actions are
    - List
    - Read
    - Tagging
    - Write
  - Certain service have certain extra Actions associated with itself.
- Resources
  - We can restrict the Actions allowed on Services selected to specific resources. 
  - We may not have to provide the full access.
  - The access can be restricted to even a particular ARN.
- Request Conditions
  - The policy can also specify if the 
    - MFA is required for the access
    - Only a particular public IP should be 
  - We also restrict using the time or the day and various other parameters.
  - All the conditions if selected is **AND** ed

We can also take a easy way out, by **"Import Managed Policy"** and then modifying it to our need.

After selecting the above information we are only left with providing

- Tags 
- Review

### JSON Editor[¶](#json-editor "Permanent link")

We can use JSON editor if we understand the JSON syntax, and the format in which AWS wants the KEY/Value pairs. We can also import an existing policy and then edit the JSON.

## Conclusion[¶](#conclusion "Permanent link")

To summarize, IAM policy is a document representing the permission encapsulated inside for a USER or a Role.

The default policy on IAM is non explicit deny, but though IAM we can give either an explicit deny or an explicit allow. The explicit deny always takes precedence over any explicit allow.

IAM policy are categorized into either managed by AWS, or user created. There are many AWS managed policy and the most useful once are Administrator policy, Power user policy and Read Only Policy.

The IAM policy is a JSON statement, and having these 3 statement at the minimum

- Effect
- Action
- Resource

IAM policy can be created by using the custom visual editor or the IAM JSON editor. Generally for new users the visual editor is beneficial once the user becomes comfortable, we can change to JSON editor.

Multiple policy can be applied to Groups and Users. Roles are used for AWS resources.

## Reference[¶](#reference "Permanent link")

- Photo by [Ales Nesetril](https://unsplash.com/@alesnesetril) on [Unsplash](https://unsplash.com/s/photos/technology)
- [Creating IAM policies (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-visual-editor)