# IAM Policies

## What is AWS IAM Policies?

AWS policies are JSON documents used to define permissions. They answer the question:

"Who can do what, on which resources, under what conditions?"

They are used to allow or deny access to AWS resources.

**Basic Concept:** 

Imagine you're running a shoe store. You have staff (users), rooms (resources), and roles (e.g., cashier, manager).

* 🔐 A policy is like a rule:\
  ➤ "Only the cashier can access the cash register."

In AWS:

* 👤 Users/Roles = People/Systems
* 📦 Resources = AWS services (S3 buckets, EC2, etc.)
* 🛡️ Policy = Access rule

## **Types of Policies:** 

| Policy Type            | Attached To           | Controls Access For...                |
| ---------------------- | --------------------- | ------------------------------------- |
| Identity Policy        | User / Group / Role   | What the identity can do              |
| Resource Policy        | S3, KMS, Lambda, etc. | Who can access the resource           |
| Trust Policy           | IAM Role              | Who can assume the role               |
| Service Control Policy | AWS Account / OU      | Limits max permissions for an account |
| Session Policy         | Temporary Sessions    | Restrict access for a session         |

### Where Are AWS Policies Applied?

AWS policies are mainly applied to:

#### 🔹 Identities (Users, Groups, Roles)

🔐 These are called Identity-Based Policies

✅ Attached to:

* IAM Users
* IAM Groups
* IAM Roles

📌 Effect: Defines what actions that identity is allowed/denied to perform on specific AWS resources.

🧠 Example:\
"Allow `user Bob` to list all S3 buckets."

```
"Action": "s3:ListBucket",
"Resource": "*"
```

### These are called Resource-Based Policies

Attached directly to:

* S3 Buckets
* SQS Queues
* SNS Topics
* KMS Keys
* Lambda functions
* Secrets Manager

📌 Effect: Grants access to the resource from other AWS accounts, services, or roles.

🧠 Example:\
Allow another AWS account to access an S3 bucket:

```
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
}
```

### IAM Roles — via Trust Policies

 These are Trust Policies that define who can assume a role.

✅ Attached to IAM roles only

📌 Effect: Says which identity/service can assume the role using `sts:AssumeRole`.

🧠 Example:

```
"Principal": { "Service": "ec2.amazonaws.com" },
"Action": "sts:AssumeRole"

```

Entire AWS Accounts (Only with AWS Organizations)

These are Service Control Policies (SCPs)

✅ Attached to:

* AWS Accounts inside an Organization
* Organizational Units (OUs)

📌 Effect: Apply a "guardrail" across the entire account — no user can override it.

🧠 Example:\
Block the use of `EC2` in an entire account:

```
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "*"

```

## **Temporary Sessions**

 These are Session Policies

✅ Applied to:

* Temporary credentials created via `AssumeRole`, `Federation`, or AWS SSO

📌 Effect: Temporarily limits permissions during that session

🧠 Example: A federated user can only access DynamoDB for 1 hour

Not Applied To:

Specific AWS Regions (but you can restrict access to a region using Condition)

```
"Condition": {
  "StringEquals": { "aws:RequestedRegion": "us-east-1" }
}
Specific Availability Zones (only via resource-level conditions)

```

| Policy Type            | Attached To           | Controls Access For...                |
| ---------------------- | --------------------- | ------------------------------------- |
| Identity Policy        | User / Group / Role   | What the identity can do              |
| Resource Policy        | S3, KMS, Lambda, etc. | Who can access the resource           |
| Trust Policy           | IAM Role              | Who can assume the role               |
| Service Control Policy | AWS Account / OU      | Limits max permissions for an account |
| Session Policy         | Temporary Sessions    | Restrict access for a session         |

**Policy Structure:**

```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "OptionalStatementID",
"Effect": "Allow" or "Deny",
"Principal": { ... }, // (Only in resource/trust policies)
"Action": "service:Action", // or list of actions
"Resource": "arn:aws:...", // or list of ARNs
"Condition": { ... } // Optional
}
]
}
```

| Component     | Description                                                                  |
| ------------- | ---------------------------------------------------------------------------- |
| `"Version"`   | Policy language version (always use `"2012-10-17"` — it's the latest stable) |
| `"Statement"` | Main section containing permission rules (can be one or many)                |
| `"Effect"`    | Allow or Deny                                                                |
| `"Action"`    | What action is allowed/denied (e.g., `s3:GetObject`, `ec2:StartInstances`)   |
| `"Resource"`  | What resource it applies to (like a specific S3 bucket)                      |
| `"Principal"` | **(only in trust or resource policies)** Who the policy applies to           |
| `"Condition"` | **(optional)** Add extra filters like time, IP, tags                         |

## **Inline vs Managed Policies:** 

| Type             | Description                                       |
| ---------------- | ------------------------------------------------- |
| Inline Policy    | Attached directly to one user/role, tightly bound |
| Managed Policy   | Reusable and attachable to multiple identities    |
| AWS Managed      | Provided by AWS (e.g., `AmazonS3ReadOnlyAccess`)  |
| Customer Managed | You create and manage it                          |

**Permission Boundarie**

Acts like a "fence" that limits what a role/user can do even if a policy allows it.

🔐 Use case: Let junior admins create EC2s, but restrict them from deleting.

Restrict what accounts in your AWS Organization can do, even if a user has Admin rights.

Example:

Block entire account from using S3:

```
{
"Effect": "Deny",
"Action": "s3:",
"Resource": ""
}
```

Advanced Conditions

Conditions let you fine-tune access:

```
"Condition": {
"StringEquals": { "aws:username": "Bob" },
"Bool": { "aws:MultiFactorAuthPresent": "true" },
"IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
}
```

Combine 2-3 conditions to enforce secure access

Examples of IAM Policies:

<pre><code>> Allow Read Access to S3 Bucket
<strong>{
</strong>  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

> Allow EC2 to Assume a Rol

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

<strong>> Block S3 Access from Outside Corporate IP
</strong>
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": "192.168.1.0/24"
        }
      }
    }
  ]
}

> Trust/Resource Policie

"Principal": { "AWS": "arn:aws:iam::123456789012:user/Bob" }
"Principal": { "Service": "ec2.amazonaws.com" }
"Principal": "*"  // Everyone (be careful!)


> Block entire account from using S3

{
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": "*"
}

> Conditions let you fine-tune access
"Condition": {
  "StringEquals": { "aws:username": "Bob" },
  "Bool": { "aws:MultiFactorAuthPresent": "true" },
  "IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
}

> AssumeRole
"Principal": { "Service": "ec2.amazonaws.com" },
"Action": "sts:AssumeRole"


<strong>
</strong><strong>
</strong>
</code></pre>