IAM Policies are JSON documents that define permissions for AWS users, groups, or roles, specifying what actions can be taken on specific AWS resources. They are crucial for managing access control across AWS environments.

Key Elements of an IAM Policy

1. Actions: Specifies what actions are allowed or denied, such as s3:PutObject for uploading objects to an S3 bucket.
2. Resources: Defines which AWS resources the policy applies to, like specific S3 buckets or EC2 instances.
3. Effect: Indicates whether the action is Allow or Deny. Deny statements always override Allow statements, ensuring restrictive security.
4. Conditions: Optional constraints that add flexibility to policies, such as allowing access only from certain IP addresses.

Types of IAM Policies

1. Identity-based Policies: Attach directly to IAM identities (users, groups, roles):
   • Managed Policies: Either AWS-managed or customer-managed, and can be reused across multiple identities.
   • Inline Policies: Directly embedded into a single user, group, or role for specific and immediate permissions.
2. Resource-based Policies: Attach directly to resources like S3 buckets or SNS topics. They allow cross-account access by specifying external AWS accounts or roles.

Best Practices for IAM Policies

• Use least privilege: Grant the minimum permissions needed for each identity to reduce security risks.
• Regularly review policies: Adjust permissions as roles and responsibilities evolve.
• Use roles for cross-account access: Assign roles rather than permanent credentials for access to other AWS accounts, and enable MFA (Multi-Factor Authentication) for sensitive actions.

Policy Evaluation

When evaluating policies, AWS applies deny overrides across all policies: if any policy contains a Deny statement, it will override all Allow statements, providing an extra layer of protection against unauthorized actions.

Example

• AdminPolicy
  • Actions: "*" (all actions)
  • Resources: "*" (all resources)
  • Effect: Allow
  • Usage: Attached to the Admins Group so members like Alice have unrestricted access to AWS resources.
• DevReadOnlyPolicy
  • Actions: ["s3:GetObject", "ec2:DescribeInstances"] (read-only access to S3 and EC2)
  • Resources: Specific S3 bucket (arn:aws:s3:::dev-bucket/*) and all EC2 instances
  • Effect: Allow
  • Usage: Attached to the Developers Group to allow users like Bob to read data without modifying it.
• LimitedS3WritePolicy
  • Actions: ["s3:PutObject", "s3:DeleteObject"]
  • Resources: Specific bucket path (arn:aws:s3:::project-bucket/uploads/*)
  • Effect: Allow
  • Conditions: Can only perform actions during business hours, specified in conditions.
  • Usage: Attached to specific users in Developers Group who need write access under constraints.