This is who IAM

AWS Identity and Access Management (IAM) is a core service that allows fine-grained access control to AWS resources. When properly configured, IAM ensures security, compliance, and productivity in cloud usage.

I. IAM: Core Components and Concepts  

IAM is based on entities and policies.

IAM Entities  

• Users: Represent people or applications. Example: a developer named “alice”.
• Groups: Collections of users sharing the same permissions.
• Roles: IAM entities that can be temporarily assumed by others. Ideal for federation or services like EC2 or Lambda.
• Policies: JSON documents that define permissions attached to an entity.

Sample JSON Policy  

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::example_bucket"
    }
  ]
}

This IAM policy allows an AWS entity (user, role, or group) to list the objects in a specific S3 bucket named example_bucket. It uses the standard IAM version format (2012-10-17) and allows the s3:ListBucket action on the resource identified by its ARN. It lets the entity see the list of objects (names, sizes, metadata), but not read or modify them—unless additional permissions are granted. This minimal policy is often used for inventory or bucket navigation via the AWS Console or API.

II. Permission Management: From Least Privilege to Delegation  

IAM relies on the Least Privilege Principle: each entity gets only the permissions strictly necessary.

Resource-Based Access Control  

Some AWS services allow fine-grained resource access control. Examples:

• S3: Permissions at the bucket and object level.
• Lambda: Permissions on invocation, management, and logs.
• DynamoDB: Access to tables, items, or specific operations.

Comparison Table: IAM Policy vs Service-Level Control  

III. Real-World Use Cases: IAM in Action  

1. Web Application with External Users  

Use Cognito to manage authentication, then IAM assigns temporary roles using JWTs to access S3 or DynamoDB.

2. Secure Deployment with IAM Roles for Service Accounts (IRSA)  

In an EKS cluster, assign an IAM role to a Kubernetes service to limit access to only the necessary S3 buckets.

3. Auditing and Compliance  

IAM integrates with AWS CloudTrail to log every API call—useful for:

• Security audits,
• Anomaly detection,
• Regulatory compliance (GDPR, HIPAA…).

IV. Best Practices and Recommendations  

• Avoid using the root user except for critical tasks.
• Enable multi-factor authentication (MFA) for human users.
• Segment permissions by roles per project or environment (dev, staging, prod).
• Regularly audit permissions using AWS IAM Access Analyzer.
• Use conditional permissions to apply constraints (time, IP, tags, etc.).

V. Spotlight on IAM Conditional Policies  

A. Introduction  

Conditional IAM policies add dynamic and contextual rules to permissions. Useful for restricting access based on:

• IP address
• Time
• Resource tags
• MFA presence, etc.

B. Structure of an IAM Condition  

A Condition clause is added within a Statement block. Example:

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*",
  "Condition": {
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

This IAM policy allows all S3 actions ("s3:*") on all resources only if the request originates from an IP address within 203.0.113.0/24. The Condition clause restricts access based on the source IP (aws:SourceIp), reinforcing security by limiting permissions to a specific network—like a corporate office or VPN.

C. Common Condition Types  

D. Use Case Examples  

Case 1: Access only during business hours

"Condition": {
  "DateGreaterThan": { "aws:CurrentTime": "2025-04-09T08:00:00Z" },
  "DateLessThan": { "aws:CurrentTime": "2025-04-09T18:00:00Z" }
}

Case 2: Deny access without MFA

"Condition": {
  "BoolIfExists": {
    "aws:MultiFactorAuthPresent": "true"
  }
}

Case 3: Permission based on tags

"Condition": {
  "StringEquals": {
    "aws:RequestTag/Environment": "prod"
  }
}

E. Best Practices  

• Always test with IAM Policy Simulator.
• Prefer short, modular policies.
• Use conditions to tighten temporary permissions.
• Combine with AWS Organizations and SCPs for full governance.

VI. Combining IAM and AWS Organizations  

A. Why Use a Multi-Account Architecture  

A multi-account structure offers:

• Isolation between environments (prod, dev, test),
• Reduced attack surface,
• Separation of responsibilities,
• Granular cost control.

However, it increases permission complexity—where AWS Organizations helps.

B. Overview of AWS Organizations  

AWS Organizations lets you:

• Create a logical hierarchy of accounts using organizational units (OUs),
• Apply global Service Control Policies (SCPs),
• Centralize billing and budget management.

SCPs define what a member account is allowed to do, regardless of local IAM policies.

C. How SCPs Work  

SCPs apply at the account or OU level, filtering effective permissions.

🔐 Note: IAM policies can never override an SCP.

D. Implementation Example  

1. Create an organization with AWS Organizations.
2. Add OUs: prod, dev, sandbox.
3. Attach a restrictive SCP to sandbox:

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

4. Grant more permissive access via IAM in dev.

E. Cross-Account Access with IAM  

To allow an entity in Account A to access resources in Account B:

• Create an IAM role in Account B, trusted by Account A.
• Use an AssumeRole policy.

Example in Account B:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::123456789012:root" },
  "Action": "sts:AssumeRole"
}

Conclusion  

AWS IAM is a foundational pillar of any cloud security strategy. Though initially complex, it’s essential for maintaining a secure, structured, and scalable AWS environment. Mastering IAM concepts and best practices ensures your cloud infrastructure is built on strong, flexible access controls.

🔗 Useful Resource  

• AWS IAM official documentation