Mastering IAM Permissions for AWS Principals

This study guide focuses on the fundamental security pillar of AWS: Identity and Access Management (IAM). Understanding how to define and manage permissions for principals is a core competency for any AWS Developer.

Learning Objectives

By the end of this guide, you should be able to:

• Differentiate between the Root user and IAM users.
• Explain the Principle of Least Privilege (POLP) and its application.
• Define the structure of an IAM Policy (JSON).
• Distinguish between IAM Roles, Service Roles, and Service-linked Roles.
• Compare IAM policies and resource-based policies (e.g., S3 Bucket Policies).

Key Terms & Glossary

• IAM Principal: An entity that can make a request for an action or operation on an AWS resource (e.g., User, Role).
• POLP (Principle of Least Privilege): The security practice of providing only the minimum permissions necessary to perform a task.
• STS (Security Token Service): A web service that enables you to request temporary, limited-privilege credentials for IAM users or for users you authenticate (federated users).
• Trust Policy: A document associated with a role that defines which principals are allowed to "assume" that role.
• Instance Profile: A container for an IAM role that you can use to pass role information to an EC2 instance at launch.

The "Big Idea"

In the AWS ecosystem, authentication (who are you?) is useless without authorization (what are you allowed to do?). IAM permissions act as the gatekeeper. Every single request made to an AWS service—whether by a human in the console, a script in the CLI, or an application in an EC2 instance—is evaluated against these permission sets. Mastering IAM is about moving away from the "all-access" Root user and toward granular, temporary, and specific identities.

Formula / Concept Box

The Anatomy of an IAM Policy Statement

Every IAM policy is a JSON document. A statement typically includes these four elements:

Hierarchical Outline

1. The Root User
   • Primary owner created with the account.
   • Unrestricted Access: Power to close the account.
   • Best Practice: Use only for initial setup; never use for daily operations.
2. IAM Users & Groups
   • IAM Users: Identities for humans or applications; start with zero permissions by default.
   • IAM Groups: Collections of users used to apply policies to multiple people at once.
3. IAM Roles
   • Temporary Credentials: Does not have long-term passwords or access keys.
   • Use Cases: Cross-account access, EC2 application permissions, and Federation.
4. Policy Types
   • Identity-based Policies: Attached to a user, group, or role.
   • Resource-based Policies: Attached to a resource (like an S3 bucket or SQS queue).

Visual Anchors

How an EC2 Instance Accesses S3

This diagram shows the relationship between an EC2 instance, an Instance Profile, a Role, and the target Resource.

Principal and Resource Interaction

The following TikZ diagram illustrates the evaluation of a request at the boundary of a resource.

Definition-Example Pairs

• Principal
  • Definition: The "Who" requesting an action.
  • Example: A developer named 'Jane' using the AWS CLI to list files in a bucket.
• Service-Linked Role
  • Definition: A predefined role linked to a specific AWS service that allows that service to call other services on your behalf.
  • Example: Auto Scaling needs a service-linked role to terminate EC2 instances when a group shrinks.
• Pre-signed URL
  • Definition: A URL that provides temporary access to an object using the permissions of the person who generated it.
  • Example: A video streaming app generates a URL that lasts 20 minutes so a user can download a private MP4 file.

Worked Examples

Example 1: Granting Read-Only S3 Access to an EC2 App

Scenario: You have a Python app on EC2 that needs to read configuration files from my-config-bucket.

1. Create Policy: Create a JSON policy that allows s3:GetObject and s3:ListBucket on the specific ARN.
   jsonCopy

   { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "arn:aws:s3:::my-config-bucket/*" } ] }
2. Create Role: Create an IAM Role with a trust policy allowing the ec2.amazonaws.com service to assume it.
3. Attach Policy: Attach the policy from step 1 to the role.
4. Assign Instance Profile: Attach the role to the EC2 instance. The SDK inside the Python app will automatically pick up the credentials via the metadata service.

Checkpoint Questions

1. What is the main difference between an IAM User and an IAM Role regarding credentials?
2. True or False: An IAM User created through the console has full Administrative access by default.
3. Why is it recommended to attach a service role to an EC2 instance at launch rather than later?
4. Which AWS service is responsible for generating the temporary credentials used when a principal assumes a role?
5. How do Pre-signed URLs solve the problem of granting access to unknown users?

[!TIP] Quick Answer Key:

1. Users have long-term credentials (password/access keys); Roles provide temporary credentials via STS.
2. False (they have zero permissions initially).
3. To ensure security and intended settings from the very start of the instance lifecycle.
4. AWS STS (Security Token Service).
5. They allow access without requiring the end-user to have an IAM identity, relying instead on the generator's permissions.