3.4.1.5. Designing Policies for Least Privilege Access

3.4.1.5. Designing Policies for Least Privilege Access

Least privilege means granting exactly the permissions needed. In practice, this requires iterative refinement.

Least privilege workflow:

1. Start with broader permissions (e.g., s3:* on specific buckets)
2. Enable CloudTrail and IAM Access Analyzer
3. After 90 days, generate a policy from actual usage
4. Replace broad policy with generated least-privilege policy
5. Monitor for access denied errors and adjust

# Generate policy from CloudTrail activity
aws accessanalyzer start-policy-generation \
  --policy-generation-details '{
    "principalArn": "arn:aws:iam::123456789012:role/AppRole",
    "cloudTrailDetails": {
      "trailArn": "arn:aws:cloudtrail:us-east-1:123456789012:trail/main",
      "startTime": "2025-01-01T00:00:00Z",
      "endTime": "2025-03-31T23:59:59Z"
    }
  }'

Policy design patterns:

• Resource scoping: "Resource": "arn:aws:s3:::my-bucket/*" not "*". Object actions (s3:GetObject, s3:PutObject) need the /* object ARN; the bare bucket ARN matches only bucket-level actions such as s3:ListBucket
• Condition keys: Restrict by IP, VPC, MFA, tags
• ABAC: "Condition": {"StringEquals": {"aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"}}

Exam Trap: iam:PassRole is frequently overlooked. When creating Lambda/ECS/EC2 resources, the user passes an IAM role to the service. The user needs iam:PassRole on the role ARN. If a developer can't create a Lambda function despite having lambda:CreateFunction, the missing permission is almost certainly iam:PassRole. Unrestricted iam:PassRole is also a privilege-escalation path: a developer who can create functions and pass any role can pass an admin role and run code with it. Scope Resource to the specific roles they may pass (optionally with the iam:PassedToService condition).