Why Least privilege principle in AWS? - Purpose & Use Cases

The Big Idea

What if a single wrong permission could open the door to your entire cloud kingdom?

The Scenario

Imagine you have a big office building and you give every employee a key that opens every door, including the server room and the CEO's office.

It sounds convenient, but what if someone loses their key or misuses it?

The Problem

Giving everyone full access is risky and can lead to mistakes or security breaches.

Manually tracking who should have access to what is slow and confusing.

It's easy to accidentally give too many permissions or forget to remove them when someone leaves.

The Solution

The least privilege principle means giving each person or system only the access they absolutely need to do their job.

This limits damage if something goes wrong and makes managing permissions clearer and safer.

Before vs After

✗ Before

UserPermissions = ['read', 'write', 'delete', 'admin']

✓ After

UserPermissions = ['read']  # Only what is needed

What It Enables

It enables secure, manageable, and efficient control over who can do what in your cloud environment.

Real Life Example

In AWS, a developer only gets permission to deploy code, not to delete databases or change billing settings.

Key Takeaways

Giving only necessary access reduces risks.

It simplifies permission management.

It protects your cloud resources from accidental or malicious actions.

Practice

1. What does the least privilege principle mean in AWS security?

easy

A. Users get only the permissions they need to do their job

B. Users get full access to all AWS services

C. Users share passwords to access resources

D. Users can access resources without authentication

Solution

1. Step 1: Understand the principle meaning

   The least privilege principle means giving users only the minimum permissions they need.

2. Step 2: Compare options to principle

   Only Users get only the permissions they need to do their job matches this by limiting permissions to what is needed.

3. Final Answer:

   Users get only the permissions they need to do their job -> Option A

4. Quick Check:

   Least privilege = minimal needed access [OK]

Hint: Least privilege means minimum permissions needed [OK]

Common Mistakes:

• Thinking least privilege means full access
• Confusing least privilege with no access
• Assuming password sharing is secure

2. Which IAM policy snippet follows the least privilege principle for allowing S3 read-only access to a specific bucket my-bucket?

easy

A. {\"Effect\": \"Allow\", \"Action\": [\"s3:DeleteObject\"], \"Resource\": \"arn:aws:s3:::my-bucket/*\"}

B. {\"Effect\": \"Allow\", \"Action\": \"s3:*\", \"Resource\": \"*\"}

C. {\"Effect\": \"Allow\", \"Action\": [\"s3:GetObject\"], \"Resource\": \"arn:aws:s3:::my-bucket/*\"}

D. {\"Effect\": \"Allow\", \"Action\": [\"ec2:StartInstances\"], \"Resource\": \"*\"}

Solution

1. Step 1: Identify required permissions for read-only S3 access

   Read-only means allowing only s3:GetObject on the specific bucket's objects.

2. Step 2: Match policy actions and resources

   {\"Effect\": \"Allow\", \"Action\": [\"s3:GetObject\"], \"Resource\": \"arn:aws:s3:::my-bucket/*\"} allows only s3:GetObject on my-bucket objects, following least privilege.

3. Final Answer:

   Policy allowing only s3:GetObject on my-bucket objects -> Option C

4. Quick Check:

   Least privilege = specific action + resource [OK]

Hint: Allow only needed actions on specific resources [OK]

Common Mistakes:

• Using wildcard * for all actions or resources
• Allowing delete or write actions unnecessarily
• Granting permissions for unrelated services

3. Given this IAM policy snippet, what is the effective permission granted?

{
  "Effect": "Allow",
  "Action": ["s3:PutObject", "s3:GetObject"],
  "Resource": "arn:aws:s3:::example-bucket/*"
}

medium

A. Denies all access to example-bucket

B. Allows uploading and downloading objects only in example-bucket

C. Allows full access to all S3 buckets

D. Allows deleting objects in example-bucket

Solution

1. Step 1: Analyze actions in the policy

   The policy allows s3:PutObject (upload) and s3:GetObject (download) actions.

2. Step 2: Check resource scope

   The resource is limited to objects inside example-bucket, so permissions apply only there.

3. Final Answer:

   Allows uploading and downloading objects only in example-bucket -> Option B

4. Quick Check:

   Actions + resource = upload/download in example-bucket [OK]

Hint: Check actions and resource ARN carefully [OK]

Common Mistakes:

• Assuming delete permission is included
• Thinking permissions apply to all buckets
• Confusing allow with deny

4. You created an IAM policy to allow only starting EC2 instances but users report they can also stop instances. What is the likely mistake?

medium

A. The users have an additional policy granting stop permissions

B. The policy includes both ec2:StartInstances and ec2:StopInstances actions

C. The policy is attached to the wrong user

D. The policy uses wildcard * for all EC2 actions

Solution

1. Step 1: Understand the reported behavior

   Users can stop instances, which is not intended by the new policy.

2. Step 2: Identify possible causes

   If the policy only allows starting, but users can stop, they likely have another policy granting stop permissions.

3. Final Answer:

   Users have an additional policy granting stop permissions -> Option A

4. Quick Check:

   Multiple policies combine permissions [OK]

Hint: Check all policies attached to users [OK]

Common Mistakes:

• Assuming one policy overrides others
• Not checking group or role policies
• Ignoring policy wildcards

5. You want to apply the least privilege principle for a developer who needs to manage Lambda functions but only in the dev-environment. Which approach is best?

hard

A. Give the developer admin access to manage Lambda

B. Create an IAM policy allowing all Lambda actions on all functions

C. Attach the AWS managed policy AWSLambdaFullAccess to the developer

D. Create an IAM policy allowing only Lambda actions on functions with resource ARN containing dev-environment

Solution

1. Step 1: Identify the scope of access needed

   The developer needs to manage Lambda functions only in the dev-environment.

2. Step 2: Apply least privilege by limiting actions and resources

   Create an IAM policy allowing only Lambda actions on functions with resource ARN containing dev-environment restricts Lambda actions to only functions in dev-environment, minimizing risk.

3. Step 3: Evaluate other options

   Options B, C, and D grant broader access than needed, violating least privilege.

4. Final Answer:

   Create an IAM policy allowing only Lambda actions on functions with resource ARN containing dev-environment -> Option D

5. Quick Check:

   Least privilege = limit actions + resource scope [OK]

Hint: Limit permissions by resource tags or names [OK]

Common Mistakes:

• Using broad AWS managed policies
• Granting admin or full access unnecessarily
• Ignoring resource-level restrictions