The Over-Privileged User

I set out to check whether a developer's IAM permissions matched the work they actually do, cut any excess down to least privilege, and move their access from a policy attached to the user to a group that scales.

A developer account, carl-the-dev, had broad permissions through a policy attached directly to the user. The role only called for three things: reading application data from one S3 bucket, describing EC2 infrastructure, and reading CloudWatch Logs for troubleshooting. I wanted the access model to be user, then a Developers group, then a scoped policy, then only the resources the job needs.

1. 01
   Enumerated the users

   I listed the IAM users in the account and picked carl-the-dev for review because of its attached policy.

2. 02
   Read the attached policy

   I pulled the policy document and confirmed the wildcard action and resource.

3. 03
   Checked for hidden access

   I looked for inline policies and group memberships, which do not show up in the managed-policy list. There were none.

4. 04
   Defined what the job needs

   Read and list on the application bucket, describe-only EC2 calls, and read-only CloudWatch Logs for the application log groups.

5. 05
   Removed the wildcard policy

   I detached it and confirmed the user had no attached policies left.

6. 06
   Wrote a scoped policy and moved to a group

   I created an AppAccess policy with only those actions, attached it to a new Developers group and added the user to the group.

# Inline policies and group membership (both empty)
aws iam list-user-policies --user-name carl-the-dev
aws iam list-groups-for-user --user-name carl-the-dev

# Remove the wildcard policy
aws iam detach-user-policy --user-name carl-the-dev \
  --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/AWS201-DevCarlAdmin

# Group-based access
aws iam create-group --group-name Developers
aws iam attach-group-policy --group-name Developers \
  --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/AppAccess
aws iam add-user-to-group --group-name Developers --user-name carl-the-dev

{
  "Statement": [
    { "Sid": "S3AppBucketReadOnly", "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["arn:aws:s3:::thm-app-data-<ACCOUNT_ID>", "arn:aws:s3:::thm-app-data-<ACCOUNT_ID>/*"] },
    { "Sid": "EC2DescribeOnly", "Effect": "Allow",
      "Action": ["ec2:DescribeInstances", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVpcs"],
      "Resource": "*" },
    { "Sid": "CloudWatchLogsReadOnly", "Effect": "Allow",
      "Action": ["logs:DescribeLogGroups", "logs:DescribeLogStreams", "logs:GetLogEvents", "logs:FilterLogEvents"],
      "Resource": "arn:aws:logs:us-east-1:<ACCOUNT_ID>:log-group:/aws/app/*" }
  ]
}

The user now belongs to Developers, and the group carries only AppAccess. I ran the policy through the IAM Policy Simulator against the application bucket:

1. 01Avoid wildcard actions and resources unless there is a documented reason.
2. 02Manage access through groups for people who do the same job.
3. 03Grant only the services, actions and resources each role needs.
4. 04Review IAM policies on a schedule for unused or excessive permissions.
5. 05Keep administrative access separate from developer access.
6. 06Watch IAM activity with CloudTrail, and prefer temporary or federated access over long-lived IAM users where you can.