IAM Basics

Identity and Access Management: users, groups, roles, policies, MFA, and least privilege.

What is it?

AWS Identity and Access Management (IAM) controls who can do what on which resources. It is global and free to use.

  • Root user: the identity created with the account, with unrestricted access. Protect it with MFA, do not use it for daily work, and do not create access keys for it.
  • IAM users: identities for a specific person or application, with long-term credentials. Prefer federation or Identity Center for humans.
  • IAM groups: collections of users, so you attach permissions once.
  • IAM roles: identities with temporary credentials that anyone (or any service) assumes. EC2 instances and Lambda functions use roles to call AWS without stored keys.
  • Policies: JSON documents that allow or deny actions. Everything is denied by default; an explicit Deny always wins.
  • MFA: a second factor that protects sign-ins.

Least privilege means granting only the permissions needed for the task. AWS IAM Identity Center gives workforce users single sign-on across accounts and applications, with permission sets mapped to roles.

Identity topics beyond users and roles

  • IAM Identity Center (successor to AWS SSO) lets workforce users sign in once and reach many accounts and applications, using its own directory or an external identity provider.
  • Identity federation lets people sign in with an identity from outside AWS (a corporate directory, SAML 2.0 or OpenID Connect provider) and receive temporary credentials, so you avoid creating an IAM user per person.
  • Cross-account access is done with an IAM role in the target account that trusts the source account; users assume the role and get temporary credentials.
  • Access keys (an access key ID plus secret) are long-term credentials for the CLI and SDKs. Rotate them, never put them in code, and prefer roles. Delete keys that are unused.
  • Password policy: an account-level IAM setting for minimum length, required character types, expiry and reuse prevention for IAM users.

Tasks only the root user can do include changing the account name, email or root password, closing the account, changing or cancelling the AWS Support plan, restoring IAM permissions when an admin locked themselves out, and enabling MFA delete on some buckets. Everything else should be done with IAM identities.

Credential reports list all IAM users and the state of their passwords, keys and MFA, and IAM Access Analyzer and access reports (last accessed information) help you find unused or overly broad permissions to trim toward least privilege.

Explain like I'm 10

IAM is the badge system of an office building. Employees (users) get badges, departments (groups) share default access, and a visiting contractor (a role) is issued a day pass that expires. The security policy printed on each badge says which doors open. The building owner's master key (root) stays locked in a safe.

Examples

A least-privilege policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOneBucket",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::zykit-demo-bucket-12345",
        "arn:aws:s3:::zykit-demo-bucket-12345/*"
      ]
    },
    {
      "Sid": "DenyUnencryptedTransport",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

Allow read-only access to one bucket, and explicitly deny any request not made over HTTPS.

A trust policy for a role (who may assume it)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Lets EC2 assume the role, so instances get temporary credentials without stored keys.

Common CLI actions

aws iam create-group --group-name developers
aws iam attach-group-policy --group-name developers \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
aws iam create-user --user-name asha
aws iam add-user-to-group --user-name asha --group-name developers
aws iam list-attached-group-policies --group-name developers

How it works

On each request, AWS evaluates all applicable policies: identity-based policies, resource-based policies, permission boundaries, and organization-level controls. The default is implicit deny. If an explicit Deny matches, the request is denied; otherwise an Allow is required somewhere applicable.

When a role is assumed, the Security Token Service (STS) issues temporary credentials that expire automatically, which limits damage if they leak.

  Request: "Can asha s3:GetObject on bucket X?"
     |
     v
  Explicit Deny anywhere? --yes--> DENIED
     | no
     v
  Some Allow that applies? --yes--> ALLOWED
     | no
     v
  Implicit deny ---------------> DENIED

Why does it exist?

Shared cloud accounts hold powerful capabilities. Without fine-grained identity and permissions, a mistake or compromised credential could affect everything. IAM lets teams limit blast radius and trace actions to identities.

When to use it

Always. Use groups for human permission management, roles for applications and cross-account access, MFA on root and privileged users, and Identity Center for workforce SSO.

When not to use it

Avoid long-lived IAM user access keys when a role or Identity Center session would work. Avoid wildcard policies ("Action": "*") outside tightly scoped, reviewed cases.

Common mistakes

  • Using the root user for everyday tasks, or creating root access keys.

  • Attaching AdministratorAccess to everyone to make errors go away.

  • Sharing one IAM user between people.

  • Embedding access keys in code or a public repo instead of using roles.

  • Forgetting that Deny overrides Allow when debugging 'access denied'.

  • Creating shared IAM users for a team instead of using Identity Center or roles.

  • Leaving old access keys active after an employee or app no longer needs them.

Practice exercises

  1. Easy:

    Enable MFA on your own account and write down which identities should have it.

  2. Medium:

    Write a policy that lets a user start and stop only EC2 instances tagged Env=dev. (Hint: use a Condition on ec2:ResourceTag/Env.)

  3. Medium:

    Paste the example policy into the JSON formatter or JSON Schema tool and explain each statement.

  4. Hard:

    Design access for three teams across two accounts using roles and Identity Center instead of per-account IAM users.

Interview questions

What is the principle of least privilege?

Grant only the permissions needed to perform a task, and no more, for the shortest necessary time.

User vs role?

A user has long-term credentials and represents a person or app; a role is assumed to get temporary credentials and is preferred for services and cross-account access.

What happens if two policies conflict, one allowing and one explicitly denying?

The explicit Deny wins.

Exam-style: How should an EC2 application securely call S3? (A) Store access keys in code (B) Attach an IAM role to the instance (C) Use the root user (D) Share a user's password

B.

Exam-style: Which should be protected with MFA and not used for daily tasks?

The AWS account root user.

Exam-style: Which service gives workforce users single sign-on across multiple AWS accounts?

AWS IAM Identity Center.

Exam-style: Which task requires the root user? (A) Launch EC2 (B) Close the account (C) Create an S3 bucket (D) Create an IAM role

B.

How do you give users in one account access to resources in another?

Create a role in the resource account that trusts the other account and have users assume it.