Designing Least Privilege AWS IAM Policies

Author

Govardhana M K
December 24, 2024

TechOps Examples

Hey — It's Govardhana MK 👋

Along with a use case deep dive, we identify the remote job opportunities, top news, tools, and articles in the TechOps industry.

IN TODAY'S EDITION

🧠 Use Case

  • Designing Least Privilege AWS IAM Policies

🚀 Top News

👀 Remote Jobs

📚️ Resources

📢 Reddit Threads

🛠️ TOOL OF THE DAY

docsify -  A magical documentation site generator. Unlike GitBook, it smartly loads and parses your Markdown files and displays them as a website.

🧠 USE CASE

Designing Least Privilege AWS IAM Policies

Long before cloud infrastructures and AWS IAM policies existed, Jerome H. Saltzer and Michael D. Schroeder introduced the Principle of Least Privilege (PoLP) in their 1975 paper, The Protection of Information in Computer Systems.

This timeless work is a must read for any cloud engineer.

Designing least privilege AWS IAM policies requires precision, and I would like to establish the framework with the below flow glimpse.

Stage 1. Understand the IAM Policy Structure

An AWS IAM policy consists of:

  • Effect: Allow or Deny.

  • Action: Specifies the AWS service operations (e.g., s3:GetObject).

  • Resource: Defines the AWS resources to which the policy applies (e.g., arn:aws:s3:::example-bucket).

  • Condition (Optional): Adds restrictions based on IP, time, or tags.

You can find a greater variety of IAM policy examples here.

Stage 2. Start by Defining Roles

Roles group permissions for specific use cases. Use these examples as a starting point:

Viewer Role

  • Purpose: Read-only access for viewing resources.

  • Actions: Describe*, List*

PowerUser Role

  • Purpose: Perform operations like reading and writing data but restricted from administrative tasks.

  • Actions: Get*, Put*, Update*

Administrator Role

  • Purpose: Full access to manage resources, used sparingly for critical tasks..

  • Actions: *

Stage 3. Define Actions with Granularity

Avoid using wildcards like * for actions.

Instead, specify only the required actions. For example:

Instead of:  Action": "s3:*

Use:

"Action": [
  "s3:ListBucket",
  "s3:GetObject"
]

Stage 4. Scope Permissions to Resources

Narrow permissions to specific resources:

Broad Resource: "Resource": "*"

Scoped Resource:

"Resource": "arn:aws:s3:::techops-bucket/*"

For multiple resources, use arrays:

"Resource": [
  "arn:aws:s3:::bucket1/*",
  "arn:aws:s3:::bucket2/*"
]

Stage 5. Use Conditions to Enforce Restrictions

Apply conditions to control when and how permissions are used:

By IP:

"Condition": {
  "IpAddress": {
    "aws:SourceIp": "192.0.2.0/24"
  }
}

By Time:

"Condition": {
  "DateGreaterThan": {
    "aws:CurrentTime": "2024-01-01T00:00:00Z"
  }
}

By MFA:

"Condition": {
  "Bool": {
    "aws:MultiFactorAuthPresent": "true"
  }
}

Stage 6. Test Policies

  • Example: Test whether PowerUser can access s3:PutObject on a specific bucket.

Debug AccessDenied errors with AWS CloudTrail to see blocked actions.

Stage 7. Map Roles to Users

Assign roles based on job functions:

  • Developers: Assign PowerUser for development accounts.

  • Ops Teams: Assign Viewer or PowerUser roles for monitoring and troubleshooting.

  • Admins: Assign Administrator role but limit access via session duration or MFA.

Use AWS Identity Center (IAM Identity Center) for centralized role assignments.

Stage 8. Monitor and Adjust Permissions

Audit roles periodically:

  • Identify unused permissions using CloudTrail.

  • Remove actions not accessed in the past 90 days.

On top of this, implement guardrails with Service Control Policies (SCPs).

You may even like:

Looking to promote your company, product, service, or event to 28,000+ TechOps Professionals? Let's work together.