AWS IAM POLICIES Deep Dive

[MyrinNew]

AWS IAM POLICIES Deep Dive

iamgroups #iamusers #iamroles #iampolicies

📌 This article is part of the AWS IAM Deep Dive series.

• Part 1: IAM Users Deep Dive
• Part 2: IAM Groups Deep Dive
• Part 3: IAM Roles Deep Dive
• Part 4: IAM Policies Deep Dive

PART 4: IAM POLICIES

aws #iam #devops #cloud

AWS IAM Policies Complete Guide

1. What is an IAM Policy?

An IAM Policy is a JSON document that defines permissions in AWS. Policies specify:

• Who can access (via users, groups, or roles)
• What actions can be performed
• On which resources (ARNs)
• Under what conditions (e.g., IP, MFA, tags)

They are the building blocks of access control in AWS, attached to identities (IAM users, groups, roles) or directly to resources (S3 buckets, KMS keys, etc.).


2. Core Characteristics of IAM Policies

Policy Types

• Managed Policies: AWS-managed or customer-managed, reusable across identities
• Inline Policies: Embedded directly into a user/group/role (one-to-one relationship)

Policy Document Structure





{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow" | "Deny",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": ["arn:aws:s3:::my-bucket/*"],
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
}
]
}

• Effect: Allow or Deny (explicit deny always wins)
• Action: API operations (e.g., ec2:StartInstances)
• Resource: Specific resources by ARN
• Condition: Contextual restrictions

Policy Evaluation Logic

Start with default deny


Apply explicit denies


Apply explicit allows

1. Common Problems With IAM Policies

🔴 Overly broad policies: Using Action:"" and Resource:""


🔴 Inline policies sprawl: Hard to manage since they are tied to a single identity


🔴 Policy size/limits: Limited to 6,144 characters; too many statements cause scaling issues


🔴 Lack of conditions: Granting access without MFA/IP conditions increases attack surface


🔴 Dependency confusion: Mixing AWS-managed and customer-managed policies without documentation

1. Solutions and Best Practices
   Policy Management
   Use customer-managed policies instead of inline for reusability

Follow least privilege principle → grant only required actions on specific resources


Use IAM Access Analyzer to validate and detect broad access


Security Hardening

Add MFA requirements in conditions


Use tags & conditions for environment-based restrictions (e.g., Environment=Prod)


Avoid attaching AdministratorAccess except for break-glass scenarios


Lifecycle Management

Version and track policies with IaC (Terraform/CloudFormation)


Regularly run IAM Access Advisor to remove unused permissions


Review SCPs in AWS Organizations for org-wide boundaries

1. Industry Examples
   Startup: Developers share a S3ReadWritePolicy (customer-managed) attached to a group; inline avoided

Enterprise: Hundreds of microservices → policies modularized per service; SCPs block public S3 buckets


Finance: MFA required for sensitive actions (ec2:TerminateInstances); quarterly compliance reviews


DevOps: Policies stored in Git, deployed via Terraform; CI/CD pipeline lints policies to prevent : mistakes

1. Interview Questions on IAM Policies
   Basic Level
   What is an IAM Policy?

Difference between AWS-managed and customer-managed policies?


Inline policy vs. managed policy?


Intermediate Level

How does IAM policy evaluation logic work?


How would you enforce least privilege?


Why is Deny more powerful than Allow?


Advanced Level

How do you design scalable IAM policies across multiple AWS accounts?


How do SCPs and IAM policies interact?


How do you restrict actions to specific environments (dev vs. prod)?

1. Hands-On Guide
   Pre-checks
   You must have IAM rights: iam:CreatePolicy, iam:AttachUserPolicy, etc.

Decide: inline or managed? AWS-managed or customer-managed?


Define scope: Actions, Resources, Conditions


Console Steps

Open IAM Console → Policies → Create policy





Choose Visual editor or JSON




Define actions (e.g., s3:GetObject)

Select resources (specific bucket ARN)

Add optional conditions (MFA, IP, tags)





Review and create





CLI Examples






# Create a customer-managed policy
aws iam create-policy \
--policy-name S3ReadOnlyPolicy \
--policy-document file://s3readonly.json











# Attach policy to a user
aws iam attach-user-policy \
--user-name dev-alice \
--policy-arn arn:aws:iam::123456789012olicy/S3ReadOnlyPolicy











# List policies attached to a group
aws iam list-attached-group-policies --group-name Developers











# Detach policy
aws iam detach-role-policy \
--role-name EC2AppRole \
--policy-arn arn:aws:iam::awsolicy/AmazonEC2ReadOnlyAccess











# Delete policy (cleanup)
aws iam delete-policy \
--policy-arn arn:aws:iam::123456789012olicy/S3ReadOnlyPolicy
Automation & Reporting











# Validate policy with Access Analyzer
aws accessanalyzer validate-policy \
--policy-document file://s3readonly.json \
--policy-type IDENTITY_POLICY











# List unused policies
aws iam list-policies --scope Local --only-attached=false







🙏 Wrapping Up

IAM Policies are the foundation of AWS security.

By writing clear, reusable, and least-privileged policies, you can build strong guardrails for your environment.


🔑 Remember:


Prefer managed over inline


Always validate with Access Analyzer


Automate with IaC for versioning and consistency


✅ Thanks for reading! If this helped, don’t forget to:


Leave a reaction and follow for more AWS/DevOps guides


Drop your questions or examples of policy misconfigurations


Share this with your team so everyone follows least privilege best practices


🚀 Stay tuned for the next deep dive in this series!




More...