IAM Policies

In this tutorial we are going to explore about the AWS IAM Policies. IAM takes care of authentication and authorization. AWS IAM Policies are JSON documents that define permissions and specify actions to the users, groups, and roles can perform on AWS resources. These policies enable fine-grained control over access, helping secure your AWS environment by granting only the permissions needed.

An IAM policy is a JSON document attached to the AWS resource that is used by the logged-in entity to authenticate itself or to the AWS resource to which secure access is required. This policy defines the scope of permission that the principal entity will have.

Key Types of IAM Policies

Based on their usage, IAM has multiple types of policies. These types are as follows:

1. Identity-Based Policies

Policies attached directly to users, groups, or roles, determining what actions they can perform and on which resources.
Identity-based policies can either be managed policies or inline policies.
- Managed Policies: Reusable policies that you can attach to multiple identities. These are discrete identity-based policies that exist independently of any other IAM resource. Managed policies can be attached to multiple IAM resources at the same time. Managed policies are further categorized into two types:
  - AWS Managed Policies: These are pre-built policies that are created and managed by AWS. These policies are ready to use but are less flexible as they cannot be modified.
  - Customer Managed Policies: These are the identity-based policies that we create and manage in our AWS account. As they are custom-built policies, we can draft and modify them according to our own specific requirements.
- Inline Policies: These are custom policies drafted during the creation of an IAM resource. Inline policies are attached with the IAM resource they are created with and get deleted when that resource is deleted. Embedded directly into a single user, group, or role. They are tightly bound to the identity and cannot be reused.

2. Resource-Based Policies

Resource-based policies are IAM policies that we can attach with AWS resources to specify the kind of access principal entities can have to them. These are inline policies and are to be drafted and managed by the AWS users.
Policies attached directly to AWS resources (like S3 buckets, SQS queues, and SNS topics), enabling cross-account access.
Resource-based policies specify permissions at the resource level and can grant access to specific AWS accounts, roles, or users, even from different accounts.

3. Permissions Boundaries

Specify the highest level of permissions that an identity-based policy can grant to an entity.
Policies that set the maximum permissions an IAM user or role can be granted. They serve as a limit, preventing users from gaining permissions beyond what the boundary specifies.
Useful for delegation, where administrators want to restrict what permissions others can assign.

4. Session Policies

Specify the highest level of permissions that an identity-based policy can grant to an entity when a temporary session is created for an entity.
Policies attached to a session when an IAM role is assumed (such as temporary credentials for EC2, STS AssumeRole, or SSO).
They are temporary and restrict permissions only for the duration of the session.

5. Access control lists (ACLs)

Define the level of access an external AWS account can have to the AWS resources. Unlike all other types of IAM policies, ACLs are not in JSON format.

6. Organizations Service Control Policies (SCPs)

Specify the highest level of permissions that an identity-based policy can grant to an entity at the organizational level.
Policies applied at the AWS Organization level, affecting all AWS accounts within the organization.
SCPs set the maximum permissions for IAM users and roles within an account, restricting the actions available even if the account or user has more permissive policies.
Commonly used to enforce governance across multiple AWS accounts.

Structure of an IAM Policy

An IAM policy is a JSON document structured as follows:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow" or "Deny",
      "Action": "service:action",
      "Resource": "arn:aws:service:region:account-id:resource",
      "Condition": {
        "ConditionType": {
          "ConditionKey": "ConditionValue"
        }
      }
    }
  ]
}

In the above JSON payload,

Version: Defines the policy language version; 2012-10-17 is the latest and commonly used version.
Statement: The primary policy element, which can contain multiple statements.
- Effect: Specifies whether the action is allowed (Allow) or denied (Deny).
- Action: Lists the specific actions (or APIs) to be allowed or denied, e.g., s3:PutObject.
- Resource: Specifies the resources the policy applies to using Amazon Resource Names (ARNs).
- Condition: (Optional) Adds conditions to the policy, restricting access based on factors like IP addresses, time of day, or request attributes.

Example Policy

A managed policy granting an S3 bucket read-only access might look like this:

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

IAM Policy Evaluation Logic

When AWS evaluates policies to determine access, it follows these rules:

Explicit Deny: If any policy explicitly denies an action, access is denied.
Explicit Allow: If there’s an allow policy without a deny, access is granted.
Implicit Deny: If no allow policy grants access, AWS denies access by default.

Best Practices for IAM Policies

Principle of Least Privilege: Only grant permissions necessary for the task.
Use Managed Policies for Common Permissions: Leverage AWS managed policies to simplify management and avoid policy misconfigurations.
Avoid Root Access: Refrain from using the root account; instead, create users and assign policies as needed.
Review and Audit Policies Regularly: Use AWS IAM Access Analyzer and AWS CloudTrail to monitor policy changes and access patterns.
Use Conditions to Limit Permissions: Add conditions to policies where possible, such as IP address restrictions or time-based conditions.

IAM policies are crucial for implementing security and access controls in AWS, offering flexible, granular permissions to resources while supporting security best practices.

That’s all about the AWS IAM Policies. If you have any queries or feedback, please write us at contact@waytoeasylearn.com. Enjoy learning, Enjoy AWS Tutorials.!!

IAM Policies