Least privilege principle in AWS - Step-by-Step Execution

Process Flow - Least privilege principle

Start: User/Service needs access

↓

Define minimum permissions needed

↓

Create policy with only those permissions

↓

Attach policy to user/service

↓

Access request made

↓

AWS checks policy permissions

↓

Allow if permission exists, else deny

↓

End: Access granted or denied

This flow shows how AWS grants access only if the user or service has the minimum permissions defined in their policy, following the least privilege principle.

Execution Sample

AWS

1. Define IAM policy with minimal permissions
2. Attach policy to user
3. User tries to access S3 bucket
4. AWS checks policy
5. Access allowed or denied

This example traces how AWS evaluates a user's access request based on a minimal permission policy.

Process Table

Step	Action	Policy Permissions	Access Requested	AWS Decision	Result
1	Define policy	s3:GetObject on bucket 'my-bucket'	-	-	Policy created with minimal S3 read permission
2	Attach policy	s3:GetObject on bucket 'my-bucket'	-	-	Policy attached to user
3	User requests access	s3:GetObject on bucket 'my-bucket'	s3:GetObject on 'my-bucket/file.txt'	Check if permission exists	Permission found
4	AWS evaluates	s3:GetObject on bucket 'my-bucket'	s3:GetObject on 'my-bucket/file.txt'	Allow	Access granted
5	User requests access	s3:GetObject on bucket 'my-bucket'	s3:DeleteObject on 'my-bucket/file.txt'	Check if permission exists	Permission not found
6	AWS evaluates	s3:GetObject on bucket 'my-bucket'	s3:DeleteObject on 'my-bucket/file.txt'	Deny	Access denied

💡 Access is granted only when requested action matches permissions; denied otherwise.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 5	Final
Policy Permissions	None	s3:GetObject on 'my-bucket'	Attached to user	Checked for s3:GetObject	Checked for s3:DeleteObject	Final permissions unchanged
Access Requested	None	None	None	s3:GetObject on 'my-bucket/file.txt'	s3:DeleteObject on 'my-bucket/file.txt'	Varies per request
AWS Decision	None	None	None	Allow	Deny	Depends on permission match

Key Moments - 2 Insights

Why is access denied when the user tries to delete an object even though they can read it?

Because the policy only grants 's3:GetObject' permission, not 's3:DeleteObject'. AWS denies actions not explicitly allowed, as shown in steps 5 and 6.

Can a user access resources not mentioned in their policy?

No. AWS only allows actions explicitly listed in the policy. If the action is missing, AWS denies access, ensuring least privilege, as seen in the denied delete request.

Visual Quiz - 3 Questions

Look at the execution table, what permission does the policy grant after step 1?

A s3:DeleteObject on 'my-bucket'

B s3:GetObject on 'my-bucket'

C Full access to all S3 buckets

D No permissions

💡 Hint

Check the 'Policy Permissions' column at step 1 in the execution table.

At which step does AWS deny access due to missing permission?

A Step 6

B Step 3

C Step 5

D Step 4

💡 Hint

Look for 'Deny' in the 'AWS Decision' column in the execution table.

If the policy also included 's3:DeleteObject', how would the result at step 6 change?

A Access would still be denied

B AWS would ignore the new permission

C Access would be granted

D User would be blocked from all actions

💡 Hint

Refer to how AWS checks permissions in steps 3 and 4 for allowed actions.

Concept Snapshot

Least Privilege Principle in AWS:
- Grant only the permissions needed.
- Define minimal IAM policies.
- Attach policies to users/services.
- AWS allows actions only if explicitly permitted.
- Deny all other actions by default.

Full Transcript

The least privilege principle means giving users or services only the permissions they need to do their job. In AWS, you create an IAM policy that lists just those permissions. Then you attach this policy to the user or service. When the user tries to do something, AWS checks if the action is allowed by the policy. If yes, access is granted; if not, access is denied. This keeps your cloud resources safer by limiting what each user or service can do.

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