IAM – Identity and Access Management

Notes

• AWS service to manage access to resources
• Allows to create users, groups, roles, policies, OIDC access, etc.
• Follows the principle of Least Privilege so granular permission set is possible
• Allow to enforce password policy
• New feat include Policy Simulator where AWS says:

  Showing if an action on a resource will be effectively allowed or denied given the permissions attached and resource specified.

Components/Keywords

Users

• generally a person who login to console
• can also be the service or apps or cli (AWS call them entities) that is using API Token to access/create resources
• access to resources is defined using permission and permissions boundary

Groups

• collection of users with similar access requirements
• you create group and add/remove users as needed
• you add permissions via policies to group which is all available to users in that group
• you can create groups a/c to role such as: developers, devops-engineers, etc.

Roles

• used to grant permissions without requiring long-term credentials
• when a role is assumed, AWS STS provides temporary security credentials for the role session. These credentials expire after a specified period
• a role can be associated with certain AWS resources or services, allowing them to obtain temporary credentials and use the permissions defined by the role
• a role can also be assumed by a user, another role, AWS service, or other trusted principal, depending on its trust policy
• like users, roles have permissions policies that define what actions the role can perform and which resources it can access
• a role has a trust policy that defines which trusted entities are allowed to assume the role and under what conditions:

  {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Effect": "Allow",
              "Principal": {
                  "AWS": "arn:aws:iam::<account_id>:user/<username>"
              },
              "Action": "sts:AssumeRole",
              "Condition": {
                  "Bool": {
                      "aws:MultiFactorAuthPresent": "true"
                  }
              }
          }
      ]
  }
  In this example, the specified IAM user is trusted to assume the role, but only when MFA is present.

Trust policy = Who can assume the role?
Permissions policy = What can the role do?

Policies

• policy can be AWS or User Defined (AWS Managed and Customer Managed)
• policy is what define permissions for users/groups/roles (in JSON or Visual Editor)
• permission can be Allow or Deny (AWS calls them Effect)
• you can specify exact what Action (list, read, write, etc.) to Allow or Deny
• you can even go granular like exactly what to list, read or write, etc.
• you can specify to which Resource(s) those Action(s) are Allowed or Denyed
• you can specify under which Condition the above rules are valid

An example would help more than talk:

Allow the Developer role to retrieve S3 objects only when MFA is enabled and the request originates from 100.92.90.80/32.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowDeveloperGetObject",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalArn": "arn:aws:iam::123456789012:role/Developer"
        },
        "IpAddress": {
          "aws:SourceIp": "100.92.90.80/32"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

Permission vs Permission Boundary

• permission defines what actions an identity is allowed to perform on AWS resources
• permission policy can grant permissions like s3:GetObject, ec2:StartInstances, etc.
• permission boundary sets the maximum permissions an identity can have
• a permission boundary does not grant permissions by itself, it only limits the permissions that can be granted by permission policies

permission policy
        │
        │ grants
        ▼
     actions
        │
        │ must also be
        │ allowed by
        ▼
permission boundary
        │
        ▼
 maximum allowed permissions

Example

permission policy
→ allow s3:* 

permission boundary
→ allow s3:GetObject

effective permission
→ only s3:GetObject

permission = what you are allowed to do
permission boundary = the maximum you are allowed to do

Trust Relationship

• trust relationship defines who or what is allowed to assume an IAM role
• it is defined by the role’s trust policy
• the trusted entity can be an IAM user, another role, AWS service, another AWS account, or other supported principal
• the trust policy can also specify conditions that must be satisfied before the role can be assumed

trusted entity
      │
      │ can assume?
      ▼
 trust policy
      │
      │ allows
      ▼
   IAM role
      │
      │ provides
      ▼
 role permissions

Example

{
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/alice"
    },
    "Action": "sts:AssumeRole"
}

this means:

alice is trusted to assume this role

remember:

trust policy = who can assume the role
permissions policy = what the role can do

Identity Provider

• identity provider is a system that verifies who a user is and provides identity information to AWS
• AWS can use an external identity provider to allow users to access AWS without creating a separate IAM user for each person
• common identity providers include Microsoft Entra ID, Okta, Google, and other SAML or OIDC providers
• after the user authenticates with the identity provider, AWS can use that identity to provide access to AWS resources

user
  │
  │ authenticate
  ▼
identity provider
  │
  │ verified identity
  ▼
AWS
  │
  │ temporary credentials / role
  ▼
AWS resources

Example

employee
   │
   ▼
Microsoft Entra ID
   │
   │ authentication
   ▼
AWS IAM Identity Center
   │
   │ assigned permissions
   ▼
AWS account

the important idea is

identity provider = system that verifies your identity
IAM role = defines what you can do after accessing AWS