IAM users, roles and policies with least privilege

IAM, Identity and Access Management, controls who can do what in an AWS account. Many screening questions are IAM questions in disguise, because most security incidents in the cloud come from too much access or leaked credentials rather than broken services.

The building blocks

• Root user: the identity created with the account. It can do everything, so turn on MFA and keep it for rare account-level tasks.
• IAM users: long-term identities for people or, less ideally, for applications. Each person should have their own.
• Groups: collections of users. Attach policies to a group such as Developers instead of to each user.
• Roles: identities with no permanent password or keys. A role is taken on temporarily by a service, an application or a user, and the credentials it gives expire on their own.
• Policies: JSON documents listing allowed or denied actions on resources.

Reading a policy

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

This statement allows reading objects in one bucket only. It does not allow listing the bucket, uploading or deleting. Being precise about action and resource is what least privilege looks like in practice.

How permissions are decided

1. By default, every request is denied.
2. If any applicable policy allows the action, it becomes allowed.
3. If any applicable policy explicitly denies the action, it is denied, no matter how many allows exist.

So an explicit deny is the strongest statement, and a missing allow is the most common reason for an "access denied" error.

Roles instead of stored keys

When an application on EC2 needs to reach S3, attach an IAM role to the instance. The application picks up temporary credentials automatically through the SDK. The tempting shortcut, copying an IAM user's access keys into a config file, leaves long-term secrets on a server and often in code repositories, where they get leaked.

Common mistakes:

• Attaching an administrator policy to fix a permission error quickly.
• Sharing one IAM user across a team, which removes accountability.
• Using wildcards like "Action": "*" when only two actions are needed.
• Making an S3 bucket public to solve an access problem for one application.

Habit: when you grant access, write down the exact actions and resources the task needs, start with only those, and add more only when a real error shows they are required.