IAM policies (JSON structure) in AWS - Deep Dive

Overview - IAM policies (JSON structure)

What is it?

IAM policies are documents written in JSON that define permissions for users, groups, or roles in AWS. They specify what actions are allowed or denied on which resources and under what conditions. These policies control access to AWS services and resources securely and precisely.

Why it matters

Without IAM policies, anyone could access any part of your cloud resources, leading to security risks and potential data loss. IAM policies solve this by letting you control who can do what, protecting your cloud environment from mistakes or attacks. This keeps your data safe and your services running smoothly.

Where it fits

Before learning IAM policies, you should understand basic AWS concepts like users, groups, roles, and permissions. After mastering IAM policies, you can explore advanced topics like policy evaluation logic, permission boundaries, and AWS Organizations for managing multiple accounts.

Mental Model

Core Idea

An IAM policy is a clear set of rules written in JSON that tells AWS who can do what to which resources and when.

Think of it like...

Think of an IAM policy like a house key with specific rules: it only opens certain doors (resources), only allows certain actions (like entering or using a room), and only works at certain times or conditions.

┌───────────────────────────────┐
│          IAM Policy            │
├─────────────┬─────────────────┤
│  Statement  │  Effect         │
│             │  Action         │
│             │  Resource       │
│             │  Condition      │
└─────────────┴─────────────────┘

Each Statement block defines a permission rule with:
- Effect: Allow or Deny
- Action: What can be done
- Resource: Where it applies
- Condition: When it applies (optional)

Build-Up - 7 Steps

1

Foundation

Basic JSON Structure of Policies

Concept: IAM policies are JSON documents with a specific structure including version and statements.

An IAM policy starts with a 'Version' field that defines the policy language version. Then it has a 'Statement' array where each item is a permission rule. Each statement includes 'Effect' (Allow or Deny), 'Action' (what operations), and 'Resource' (which AWS resources).

Result

You get a valid JSON policy that AWS can read to understand permissions.

Understanding the basic JSON layout is essential because every permission rule follows this pattern, making policies consistent and readable.

2

Foundation

Effect, Action, and Resource Explained

Concept: The core parts of a statement define what is allowed or denied, what actions are involved, and on which resources.

Effect is either 'Allow' or 'Deny'. Action is a list or single string of AWS operations like 's3:PutObject'. Resource specifies the ARN (Amazon Resource Name) of the AWS resource, like a bucket or instance. For example, allowing 's3:GetObject' on a specific bucket ARN.

Result

You can write simple rules that say exactly what is allowed or denied on specific resources.

Knowing these three parts lets you control access precisely, avoiding overly broad permissions that risk security.

3

Intermediate

Using Wildcards and Multiple Actions

🤔Before reading on: do you think you can list multiple actions in one statement or use wildcards to cover many actions? Commit to your answer.

Concept: IAM policies support wildcards and multiple actions to simplify permissions for many operations at once.

You can specify multiple actions as an array, like ['s3:GetObject', 's3:PutObject']. Wildcards like 's3:*' cover all S3 actions. This helps when you want to allow or deny many related actions without listing each one.

Result

Policies become shorter and easier to manage while still being specific enough.

Understanding wildcards and arrays helps you balance simplicity and security in your policies.

4

Intermediate

Conditions to Refine Permissions

🤔Before reading on: do you think conditions can restrict permissions based on time, IP, or other factors? Commit to your answer.

Concept: Conditions add extra rules that must be true for the permission to apply, making policies more flexible and secure.

The 'Condition' block uses key-value pairs to specify when a permission applies. For example, you can allow access only from certain IP addresses or during specific times. Conditions use operators like 'StringEquals' or 'IpAddress'.

Result

You can create policies that adapt to context, improving security by limiting when and how permissions work.

Knowing conditions lets you enforce real-world security rules, like only allowing access from your office network.

5

Intermediate

Policy Version and Its Importance

Concept: The 'Version' field defines the syntax and features available in the policy language.

Currently, the recommended version is '2012-10-17'. This version supports all modern features like conditions and policy variables. Older versions lack some capabilities and should be avoided.

Result

Using the correct version ensures your policies work as expected and support all features.

Understanding the version prevents compatibility issues and future-proofs your policies.

6

Advanced

Combining Multiple Statements Safely

🤔Before reading on: do you think multiple statements in one policy combine with AND or OR logic? Commit to your answer.

Concept: Multiple statements in a policy combine with OR logic, but Deny statements override Allows.

Each statement is evaluated independently. If any statement explicitly Denies an action, that Deny takes precedence. Otherwise, if any statement Allows it, the action is permitted. This logic helps create layered permissions.

Result

You can write complex policies that allow broad access but deny specific risky actions.

Knowing how statements combine helps avoid unexpected permission grants or denials.

7

Expert

Policy Variables and Dynamic Permissions

🤔Before reading on: do you think IAM policies can use placeholders to customize permissions per user or resource? Commit to your answer.

Concept: IAM supports variables in policies that get replaced at runtime with user or resource-specific values.

Variables like '${aws:username}' let you write one policy that adapts to the user accessing resources. For example, allowing users to access only their own folder in S3 by referencing their username dynamically.

Result

Policies become reusable and scalable, reducing duplication and errors.

Understanding variables unlocks powerful, flexible permission models that fit large organizations.

Under the Hood

When AWS receives a request, it checks the attached IAM policies by parsing their JSON structure. It evaluates each statement's Effect, Action, Resource, and Condition against the request details. Deny statements override Allows. The evaluation engine uses the policy version to interpret syntax and features. Variables are replaced with actual values at runtime before evaluation.

Why designed this way?

IAM policies use JSON for readability and machine parsing. The statement-based design allows modular, clear permission rules. The explicit Deny override ensures security by preventing accidental permission grants. Variables and conditions add flexibility without complicating the core model. This design balances security, clarity, and flexibility.

┌───────────────┐
│ AWS Request   │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Policy Engine │
│ ┌───────────┐ │
│ │Parse JSON │ │
│ └────┬──────┘ │
│      │        │
│ ┌────▼──────┐ │
│ │Evaluate   │ │
│ │Statements │ │
│ └────┬──────┘ │
│      │        │
│ ┌────▼──────┐ │
│ │Apply      │ │
│ │Conditions │ │
│ └────┬──────┘ │
│      │        │
│ ┌────▼──────┐ │
│ │Decision   │ │
│ │Allow/Deny │ │
│ └───────────┘ │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does an explicit Allow override an explicit Deny in IAM policies? Commit to yes or no.

Common Belief: If a policy explicitly Allows an action, it always succeeds regardless of other policies.

Reality: Explicit Deny always overrides any Allow, blocking the action.

Why it matters: Ignoring this can lead to unexpected access denials or security holes if Deny statements are not carefully managed.

Quick: Can you use IAM policies to grant permissions to users in other AWS accounts directly? Commit to yes or no.

Common Belief: IAM policies alone can grant cross-account access to any user.

Reality: Cross-account access requires roles and trust policies, not just IAM policies.

Why it matters: Misunderstanding this leads to failed access setups and security risks by misconfiguring permissions.

Quick: Do wildcards in IAM actions always mean all actions are allowed? Commit to yes or no.

Common Belief: Using '*' in actions means full access to all AWS services.

Reality: Wildcards can be scoped, but using '*' grants very broad permissions and should be used cautiously.

Why it matters: Overusing wildcards can create security vulnerabilities by granting more access than intended.

Quick: Does the order of statements in an IAM policy affect permission evaluation? Commit to yes or no.

Common Belief: Statements are evaluated in order, so order changes the result.

Reality: Statements are evaluated as a set; order does not affect the final decision.

Why it matters: Believing order matters can cause confusion and incorrect policy edits.

Expert Zone

1

IAM policy evaluation includes implicit denies for actions not explicitly allowed, which is a key security feature often overlooked.

2

Using policy variables can reduce the number of policies needed but requires careful testing to avoid unintended access.

3

Conditions can combine multiple operators and keys, enabling very fine-grained access control that goes beyond simple allow/deny.

When NOT to use

IAM policies are not suitable for granting temporary access to external users; instead, use IAM roles with temporary credentials. For complex multi-account setups, AWS Organizations SCPs or permission boundaries may be better. Avoid using overly broad policies with wildcards in production.

Production Patterns

In real systems, policies are modularized by function (e.g., read-only, admin), combined with roles for temporary access, and use conditions to restrict by IP or MFA. Variables are used to create user-specific access, and explicit Deny statements protect sensitive resources.

Connections

Access Control Lists (ACLs)

Both define permissions but ACLs are resource-centric while IAM policies are identity-centric.

Understanding ACLs helps grasp the difference between controlling access from the resource side versus the user side.

Role-Based Access Control (RBAC)

IAM policies implement RBAC by attaching policies to roles and users to manage permissions.

Knowing RBAC concepts clarifies why IAM uses roles and policies to simplify permission management.

Legal Contracts

IAM policies are like contracts specifying allowed actions and conditions between parties.

Seeing policies as contracts helps understand the importance of precise language and conditions to avoid misunderstandings.

Common Pitfalls

#1 Granting overly broad permissions with wildcards.

Wrong approach:

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

Correct approach:

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::example-bucket/*"
}]
}

Root cause:

Misunderstanding the security risk of wildcards leads to granting more access than necessary.

#2 Using incorrect ARN format in Resource field.

Wrong approach:

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "example-bucket/*"
}]
}

Correct approach:

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*"
}]
}

Root cause:

Not using the full ARN format causes AWS to reject or ignore the policy.

#3 Placing Condition outside Statement block.

Wrong approach:

{
"Version": "2012-10-17",
"Condition": {
"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}
},
"Statement": [{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*"
}]
}

Correct approach:

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*",
"Condition": {
"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}
}
}]
}

Root cause:

Misplacing Condition causes it to be ignored, weakening security controls.

Key Takeaways

IAM policies are JSON documents that define who can do what on which AWS resources and under what conditions.

The core parts of a policy statement are Effect, Action, Resource, and optionally Condition, which together control access precisely.

Explicit Deny always overrides Allow, ensuring security by preventing accidental permission grants.

Using variables and conditions in policies allows flexible, context-aware permissions that scale for large environments.

Understanding the JSON structure and evaluation logic is essential to write secure and effective IAM policies.