AWS IAM: Permissions and Policies ?

AWS Identity and Access Management (IAM) is a critical service that controls secure access to AWS resources. At its core, IAM governs who can do what to which resources in your cloud environment, ensuring security and operational smoothness. This blog will explore the foundational concepts of permissions and policies in AWS IAM, how they interact, and how you can leverage them effectively with practical examples.

What is AWS IAM?

AWS IAM lets you safely manage access to AWS services and resources. By using IAM, you define identities (like users, groups, and roles) and assign them permissions through policies that specify what actions they can perform on which AWS resources.

Key Concepts: Permissions vs Policies

• Permissions are the allowed or denied actions a user or system can take on AWS resources.
• Policies are the documents written in JSON format that define these permissions. Effectively: Policies describe permissions.

Types of IAM Policies

AWS supports several policy types, each with distinct purposes:

Policy Type	Description	Practical Use Case
Identity-based Policies	Attached directly to IAM users, groups, or roles. Grants permissions to the identity.	Granting a developer access to start EC2 instances.
Resource-based Policies	Attached to AWS resources (e.g., S3 bucket policies). Grant access to specified principals.	Allowing another AWS account to read your S3 bucket.
Managed Policies	Predefined by AWS or custom policies created by you, reusable across multiple entities.	AWS Managed Policy: AmazonS3ReadOnlyAccess.
Inline Policies	Embedded directly into a single user, group, or role. Not reusable.	Unique permissions needed for one specific user.
Permissions Boundaries	Define the maximum permissions an identity can have, acting as a limit rather than a grant.	Restricting junior admins from escalating privileges.
Service Control Policies (SCPs)	Used within AWS Organizations to limit permissions across all member accounts.	Forcing organization-wide restrictions on IAM changes.
Session Policies	Temporary policies passed during role assumption to limit permissions dynamically.	Restricting permissions in a federated user session.

Anatomy of an IAM Policy Document

An IAM policy is a JSON file, which includes one or more statements—each defining:

• Effect: Allow or Deny — whether the action is permitted or forbidden.
• Action: AWS service actions (e.g., s3:GetObject).
• Resource: Specifies which exact resource(s)—defined by Amazon Resource Names (ARNs)—the policy applies to.
• Condition: Optional extra controls (e.g., IP restrictions, time constraints, MFA requirements).

Example: Restricting S3 Access by IP

Here’s a sample policy allowing all S3 actions on a bucket company-data but only from your corporate IP address:

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "s3:",
"Resource": "arn:aws:s3:::company-data/",
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.10/32"
}
}
}]
}

This policy creates a strong security boundary by allowing access only from trusted network locations.

The Principle of Least Privilege

A core security practice in IAM is granting only the minimal necessary permissions for users and applications to perform their tasks. This principle reduces exposure and limits damage if credentials are compromised.

How Permissions Are Evaluated

When a principal (an authenticated user, group member, or role) attempts an AWS action:

1. AWS evaluates all relevant policies attached to the principal and to the resources involved.
2. Explicit Deny permissions in any policy take precedence and block access.
3. If no policy explicitly allows the action, it is implicitly denied.
4. If any policy grants permission and no explicit deny blocks it, the action is permitted.

For instance:

• A developer with a policy allowing ec2:StartInstances but no mention of ec2:TerminateInstances cannot terminate instances.
• If the same developer has another policy explicitly denying ec2:TerminateInstances, the deny overrides any allow.

IAM Roles and Temporary Permissions

IAM roles provide a secure method to delegate permissions without sharing long-term credentials. They are assumed by trusted entities (like EC2 instances, Lambda functions, or users from external accounts). When a role is assumed, temporary security credentials with the role’s permissions are issued.

Roles have two key policy types:

• Trust policy: Defines who can assume the role.
• Permissions policy: Defines what the role can do.

Real-World Policy Examples

1. Read-Only Access to S3 Buckets

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

This lets users list and read any S3 bucket objects without write permission.

2. Restrict Deletion Without MFA

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::sensitive-data/*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}]
}

This denies object deletion unless multi-factor authentication is enabled — adding a valuable security layer.

Advanced Controls: Permission Boundaries & SCPs

• Permission Boundaries limit the maximum permissions assignable to an IAM entity, an important safeguard in complex environments.
• Service Control Policies (SCPs) enforce account-wide or org-wide permission limits, helping comply with organizational governance and security compliance.

Best Practices for IAM Permissions and Policies

• Start with AWS Managed Policies to cover common roles but customize to tailor security.
• Use IAM Groups to simplify management by assigning policies collectively.
• Regularly review and update policies to remove unused privileges.
• Use conditions (like source IP, MFA, or VPC restrictions) to tighten security.
• Monitor permissions usage with AWS Access Advisor and IAM Access Analyzer tools.
• Audit policies for overly broad permissions (*) and minimize their use.

Wrapping Up

AWS IAM policies and permissions form a sophisticated and flexible system essential for securing your cloud environment. By understanding the different policy types, the structure of policies, how permissions are evaluated, and following best practices, you can design robust access controls that protect your resources without hindering productivity.

---

Happy Cloud Securing! ☁️🔐