AWS IAM Policies PART 1 : Identity and Resource Based Policies

IAM POLICY TYPES

AWS IAM policies are documents written in JSON that define permissions for users, groups, and roles. Policies determine which actions are allowed or denied on AWS resources. There are several types of policies in AWS IAM but in this blog post we will look at first two policy types : Identity based and Resource based

1. Identity-based Policies

These are policies that are directly attached to IAM users, groups, or roles. They control what actions the identity (user, group, or role) can perform on specific resources.

An AWS Identity-based policy is a JSON document that is attached to an IAM user, group, or role to define what actions that identity can perform on which AWS resources. These policies allow you to specify who (user, group, role) has access to what resources and what actions they can take on those resources.

Structure of an Identity-based Policy

An identity-based policy consists of:

• Version: Specifies the language syntax version.

• Statement: The main part of the policy, containing:

  • Effect: Whether the statement allows or denies access ("Allow" or "Deny").

  • Action: Lists the AWS actions the policy allows or denies (e.g., "s3:PutObject", "ec2:StartInstances").

  • Resource: Specifies which AWS resources the action applies to (e.g., an S3 bucket, an EC2 instance).

  • Condition (Optional): Adds conditions to specify when the policy is in effect, based on factors like IP address, time of day, or specific tags.

Example of an Identity-based Policy

This policy allows an IAM user to:

1. Read objects from a specific S3 bucket.

2. Start and stop EC2 instances in a specific region.

   

   Explanation of the Policy

   • Version: "2012-10-17" is the policy language version that defines the structure of the policy.

   • Statement 1:

     • Effect: "Allow" permits the action.

     • Action: "s3:GetObject" allows the user to read objects from an S3 bucket.

     • Resource: "arn:aws:s3:::example-bucket/*" specifies that the permission applies to all objects within the S3 bucket named example-bucket.

   • Statement 2:

     • Effect: "Allow" permits the actions.

     • Action: "ec2:StartInstances" and "ec2:StopInstances" allow the user to start and stop EC2 instances.

     • Resource: "arn:aws:ec2:us-west-2:123456789012:instance/*" specifies that the actions apply to all EC2 instances within the specified AWS account (123456789012) in the region us-west-2.

     • Condition: Ensures that the EC2 actions are only allowed in the us-west-2 region.

Key Components of Identity-based Policies

1. Effect: Defines whether the actions are allowed or denied.

   • "Allow": Grants access.

   • "Deny": Explicitly denies access. Deny statements always override allow statements.

2. Action: Lists one or more AWS actions that the policy affects.

   • Examples: "s3:PutObject", "ec2:StartInstances", "iam:CreateUser".

   • Actions are usually prefixed by the AWS service (e.g., "s3", "ec2").

3. Resource: Specifies the AWS resources the action applies to.

   • Examples: arn:aws:s3:::bucket-name/* for S3 objects, arn:aws:ec2:region:account-id:instance/instance-id for EC2 instances.

   • The ARN (Amazon Resource Name) format uniquely identifies resources.

4. Condition (Optional): Adds conditions to further refine when the policy is in effect.

   • Examples: Only allow access from certain IP ranges or during specific times of day.

Common Use Cases of Identity-based Policies

1. Granting S3 Bucket Access:

   • You can create a policy that gives users read-only access to objects in a specific S3 bucket.

2. Controlling EC2 Instances:

   • A policy can grant permissions to start and stop EC2 instances but prevent users from terminating them.

3. Restricting Actions Based on IP Address:

   • You can restrict actions to be allowed only when performed from a specific IP range using a condition.

4. Assigning Administrator Access:

   • A policy can grant full access to all AWS services and resources for an administrator user.

Another Example: Administrator Access Policy

The following is an example of an identity-based policy that grants full access to all AWS services (Administrator Access).

Explanation:

• Effect: "Allow" permits the actions.

• Action: "*" means all actions across all AWS services (e.g., s3:PutObject, ec2:DescribeInstances, etc.).

• Resource: "*" means the policy applies to all AWS resources.

This is a broad policy typically used for users or roles that require full control over AWS services, such as administrators.

2. Resource-based Policies

An AWS Resource-based policy is a policy that is directly attached to an AWS resource rather than to an identity (like a user or role). These policies define who can access the resource and what actions they can perform. Resource-based policies are commonly used for services like Amazon S3, AWS KMS, Amazon SNS, and Amazon SQS.

Key Characteristics of Resource-based Policies

• Attached to resources: Unlike identity-based policies, which are attached to IAM users, groups, or roles, resource-based policies are attached to AWS resources like S3 buckets, SQS queues, and SNS topics.

• Support for cross-account access: Resource-based policies can grant permissions to users, roles, or AWS accounts that do not belong to your own AWS account, enabling cross-account access without sharing credentials.

• Specify actions and resources: These policies specify who can access the resource (principals) and what actions they can perform.

Structure of a Resource-based Policy

Resource-based policies follow a similar structure to identity-based policies, but they include a Principal element, which specifies who is allowed to access the resource.

• Principal: Defines which identities (users, roles, or AWS accounts) can access the resource.

• Action: Specifies the actions allowed on the resource (e.g., s3:PutObject for S3, sqs:SendMessage for SQS).

• Resource: Identifies the specific AWS resource to which the policy applies (e.g., a specific S3 bucket or an SQS queue).

• Effect: Determines whether the action is allowed or denied ("Allow" or "Deny").

Example of a Resource-based Policy for an S3 Bucket :

This example shows a resource-based policy attached to an S3 bucket that allows users from another AWS account to read objects from the bucket.

Explanation:

• Version: "2012-10-17" defines the policy language version.

• Effect: "Allow" grants access to the specified action.

• Principal: The "AWS": "arn:aws:iam::123456789012:root" specifies that the root user (all users) in AWS account 123456789012 is allowed to access the bucket. You can specify individual users, roles, or even entire AWS accounts in the Principal section.

• Action: "s3:GetObject" allows the user to read objects from the S3 bucket.

• Resource: "arn:aws:s3:::example-bucket/*" refers to all objects within the S3 bucket named example-bucket.

This policy gives the entire AWS account 123456789012 permission to read objects from the example-bucket S3 bucket.

Example of a Resource-based Policy for an SQS Queue

Here’s an example of a resource-based policy that allows a specific AWS account to send messages to an SQS queue.

Explanation:

• Effect: "Allow" grants access to the action.

• Principal: "arn:aws:iam::123456789012:root" allows users in the AWS account 123456789012 to send messages to the SQS queue.

• Action: "sqs:SendMessage" permits the action of sending messages to the queue.

• Resource: "arn:aws:sqs:us-west-2:098765432109:example-queue" refers to the specific SQS queue that the policy is applied to (example-queue).

This policy allows the AWS account 123456789012 to send messages to the example-queue SQS queue in the us-west-2 region.

Example of a Resource-based Policy for Cross-account Access (SNS Topic)

This example shows how a resource-based policy for an SNS topic allows another AWS account to publish messages to the topic.

Explanation:

• Effect: "Allow" grants the permission.

• Principal: The "AWS": "arn:aws:iam::112233445566:root" specifies that the root user of AWS account 112233445566 can publish to the SNS topic.

• Action: "sns:Publish" allows the publishing of messages to the topic.

• Resource: "arn:aws:sns:us-east-1:123456789012:example-topic" specifies the SNS topic (example-topic) in the us-east-1 region.

This policy allows users in the 112233445566 account to publish messages to the example-topic SNS topic in account 123456789012.

Here’s an example of an AWS resource-based policy for an S3 bucket that includes encryption requirements. This policy allows users from a specific AWS account to upload objects to the S3 bucket, but only if they use server-side encryption (SSE-S3) to encrypt the objects.

Explanation:

1. Version:

   • The "2012-10-17" version indicates the policy format and structure used.

2. Statement 1:

   • Effect: "Allow" grants permission.

   • Principal: "arn:aws:iam::123456789012:root" allows all users from AWS account 123456789012 to upload objects to the S3 bucket.

   • Action: "s3:PutObject" allows the users to upload objects.

   • Resource: "arn:aws:s3:::example-bucket/*" specifies the S3 bucket (example-bucket) and all objects within it.

   • Condition:

     • The "s3:x-amz-server-side-encryption": "AES256" condition requires that the uploaded objects be encrypted using server-side encryption with AES-256 (SSE-S3).

3. Statement 2:

   • Effect: "Allow" grants permission to read the objects.

   • Principal: "arn:aws:iam::123456789012:root" allows users from the specified AWS account to read objects in the bucket.

   • Action: "s3:GetObject" allows users to download objects from the bucket.

   • Resource: "arn:aws:s3:::example-bucket/*" refers to all objects within the example-bucket.

Key Elements in the Policy

• Principal:

  • This defines which identities (in this case, all users in the 123456789012 AWS account) can perform the specified actions.

• Action:

  • "s3:PutObject" allows users to upload objects to the S3 bucket.

  • "s3:GetObject" allows users to download objects from the S3 bucket.

• Condition:

  • The condition ensures that only objects encrypted using SSE-S3 (server-side encryption with AES-256) are allowed to be uploaded. The specific condition is defined by the "s3:x-amz-server-side-encryption": "AES256" key-value pair.

How the Policy Works

• This policy grants users from the 123456789012 AWS account permission to upload and read objects in the S3 bucket named example-bucket.

• However, the condition enforces that any uploaded objects must be encrypted using the AES256 encryption method (SSE-S3). If the encryption is not applied during upload, the PutObject action will be denied.

Enforcing Encryption in S3 Uploads

When uploading objects to S3 using this policy, the users or applications must specify the encryption method in their request. For example, if using the AWS CLI, the following command includes the encryption parameter:

This ensures that the uploaded file is encrypted with server-side encryption using AES-256, satisfying the policy condition.

Here's an example of an AWS resource-based policy for an S3 bucket that enforces the use of AWS KMS (Key Management Service) encryption. This policy allows users from a specific AWS account to upload and read objects from the S3 bucket, but only if the objects are encrypted using a specific AWS KMS key.

Explanation:

1. Version:

   • "2012-10-17" specifies the policy language version.

2. Statement 1:

   • Effect: "Allow" grants permission.

   • Principal: "arn:aws:iam::123456789012:root" specifies that the permission applies to all users in AWS account 123456789012.

   • Action: "s3:PutObject" allows users to upload objects to the S3 bucket.

   • Resource: "arn:aws:s3:::example-bucket/*" specifies that the permission applies to all objects in the example-bucket.

   • Condition:

     • "s3:x-amz-server-side-encryption": "aws:kms" enforces that the uploaded objects must be encrypted using AWS KMS encryption.

     • "s3:x-amz-server-side-encryption-aws-kms-key-id" ensures that the specified KMS key (arn:aws:kms:us-west-2:123456789012:key/abcd1234-5678-90ab-cdef-EXAMPLEKEYID) is used for encryption.

3. Statement 2:

   • Effect: "Allow" grants permission.

   • Principal: "arn:aws:iam::123456789012:root" allows users from the same AWS account to download objects from the bucket.

   • Action: "s3:GetObject" allows users to read objects from the S3 bucket.

   • Resource: "arn:aws:s3:::example-bucket/*" specifies the S3 bucket and all objects in it.

Key Elements in the Policy

• Principal: Defines which AWS account or users can perform actions on the resource (in this case, the root user of AWS account 123456789012).

• Action:

  • "s3:PutObject": Grants permission to upload objects to the S3 bucket.

  • "s3:GetObject": Grants permission to download objects from the S3 bucket.

• Condition:

  • "s3:x-amz-server-side-encryption": "aws:kms" enforces that the uploaded objects must use AWS KMS for encryption.

  • "s3:x-amz-server-side-encryption-aws-kms-key-id" specifies the exact KMS key (via ARN) that must be used for encryption. If any other KMS key is used, the PutObject action will be denied.

• Resource: Specifies the S3 bucket (example-bucket) and the objects within it.

How the Policy Works

1. PutObject Action (Upload):

   • Users from AWS account 123456789012 can upload objects to the example-bucket.

   • The uploaded objects must be encrypted using AWS KMS ("s3:x-amz-server-side-encryption": "aws:kms").

   • The specific KMS key used for encryption must be the one with the ARN "arn:aws:kms:us-west-2:123456789012:key/abcd1234-5678-90ab-cdef-EXAMPLEKEYID". If any other key or encryption method is used, the upload will fail.

2. GetObject Action (Download):

   • Users from the same AWS account are allowed to download objects from the bucket.

   • No specific condition is required for downloading the objects, but since the objects are encrypted with KMS, the user needs the necessary KMS permissions to decrypt the data.

   • Example AWS CLI Command with KMS Encryption

     When uploading objects with the AWS CLI, the following command specifies that the object should be encrypted using a KMS key:

   • aws s3 cp file.txt s3://example-bucket/file.txt --sse aws:kms --sse-kms-key-id arn:aws:kms:us-west-2:123456789012:key/abcd1234-5678-90ab-cdef-EXAMPLEKEYID

   • This command uploads file.txt to example-bucket and encrypts it using the specified KMS key.