Skip to main content

Identity and Access Management

https://docs.aws.amazon.com/iam/index.html

FAQs: https://aws.amazon.com/iam/faqs/

https://github.com/topics/iam

Security best practices in IAM - https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

tip

Enable IAM Access Analyzer

See some use cases at Security best practices in IAM

It can generate policies - see below

A vault for securely storing and accessing AWS credentials in development environments - https://github.com/99designs/aws-vault

Cloudsplaining is an AWS IAM Security Assessment tool that identifies violations of least privilege and generates a risk-prioritized report - https://github.com/salesforce/cloudsplaining

A tool for quickly evaluating IAM permissions in AWS - https://github.com/nccgroup/PMapper

Refining permissions in AWS using last accessed information - https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html

AWS Vault - https://github.com/99designs/aws-vault - Stores IAM credentials in your operating system's secure keystore

IAM is a global service. Notice you cannot select any region at the top-right dropdown. Any user, group, role etc. can be used on all regions, all around the world.

Summary​

  • User: an individual, system, or application requiring access to AWS services.
  • Group: collection of users. A user can be in many groups.
  • Role: set of permissions.
  • Policy: JSON file. Permissions assigned to a user, group or role.
  • Principal: user, account, service, or other entity that is allowed or denied access to a resource.

Nice summary - https://blog.awsfundamentals.com/aws-iam-roles-terms-concepts-and-examples

Cheatsheet - https://digitalcloud.training/aws-iam/

User​

By default users have no permissions, thus they can't do anything. You give them permissions using groups and policies.

Each user has a username (Account name), used to log in.

Authentication:

Service account​

An IAM user for a service or application.

IAM roles for service accounts provide the ability to manage credentials for your applications, similar to the way that Amazon EC2 instance profiles provide credentials to Amazon EC2 instances. source

Group​

A collection of users.

A way of organizing users and applying permissions to them through a policy.

Is not an identity, thus it cannot be used at the a Principal field of a policy. See https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html:

You cannot identify a user group as a principal in a policy (such as a resource-based policy) because groups relate to permissions, not authentication, and principals are authenticated IAM entities.

Role​

A way to delegate permissions without using permanent credentials. Is an identity. Roles are assumed by users, applications and services (the trusted entities).

When you assume a role you loose any other permissions. Eg if you are an admin but you assume a role, you loose the admin permissions. Thus, the permissions assigned to a role need to include everything required to complete the task.

From https://explore.skillbuilder.aws/learn/course/120/play/459/introduction-to-aws-identity-and-access-management-iam

  • Is an AWS identity with permissions that determine what can and can't do.
  • Can be assigned a policy for permissions.
  • Users, applications and services can assume roles.
  • Does not have long term credentials/passwords/access keys. Instead, if a user is assigned a role, access keys are created dynamically and provided to the user temporarily.
  • Can be used to delegate access to users, applications or services that don't normally have access to your AWS resources.
  • A user who assumes a role temporarily gives up his other own permissions and instead takes on the permissions of the role.
  • Eg we can give an EC2 instance a IAM role to temporarily access a S3 bucket using an instance profile.
  • Roles remove the need to modify a user's policy each time a change is required.

https://stackoverflow.com/questions/46199680/difference-between-iam-role-and-iam-user-in-aws

https://classroom.udacity.com/nanodegrees/nd0044/parts/8fc72c65-158a-429d-a08f-f25b8b66e99f/modules/769586dd-1c0b-4155-af83-853bc9fa7fdc/lessons/e21110af-9970-4f3c-b1ad-c8cc4f27df39/concepts/ee39a09f-e9c3-48db-93c7-d773f07bb6aa

We recommend using IAM roles for human users and workloads that access your AWS resources so that they use temporary credentials (instead of IAM users) source

A role is an identity in AWS that doesn't have its own credentials (as a user does) source

sts:AssumeRole​

The API call used to assume a role.

On a trust policy the Action is sts:AssumeRole.

https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html

https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-role.html

https://stackoverflow.com/questions/63241009/aws-sts-assume-role-in-one-command

EC2 instance profile​

A way to attach a role to an EC2 instance, for example to access other services like S3.

We need a trust policy to allow the EC2 instance to assume the role.

To create one:

  • Go to IAM → Roles, and click 'Create role'.
  • At the 'Trusted entity type' choose 'AWS service', and at the 'Use case' drop-down list select EC2 (under 'Commonly used services'). This is the trust policy.
  • Click 'Next' and select the Permissions policies.

Once the role is created, you can see the trust policy at the role's 'Trust relationship' tab, where the trusted entities is:

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

The permissions policy can be anything. For example, if we've given S3 read access with AmazonS3ReadOnlyAccess, it will be:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*",
        "s3:Describe*",
        "s3-object-lambda:Get*",
        "s3-object-lambda:List*"
      ],
      "Resource": "* "
    }
  ]
}

To attach the role to the EC2 instance, when creating an instance, select the role at the 'IAM instance profile' dropdown. And if the instance is already running, go to the EC2 console → Instances, open the instance, and on the Actions drop-down menu (top right) do Security → Modify IAM role. Select the role and click 'Update IAM role'.

Policy​

JSON file. Permissions assigned to a user, group or role.

{
  "Sid": "AllowManageOwnSSHPublicKeys", // Who/what is authorized
  "Effect": "Allow", // Or "Deny"
  "Action": [
    // Which task(s) are allowed/denied. It's an API action
    "iam:GetSSHPublicKey",
    "iam:ListSSHPublicKeys"
  ],
  "Condition": {
    // Which condition(s) need to be met for authorization
  },
  // Resources to which authorized tasks are performed. An ARN or *
  "Resource": "arn:aws:iam::*:user/${aws:username}"
}

Console: https://console.aws.amazon.com/iamv2/home?#/policies

Policy Simulator: https://policysim.aws.amazon.com

Policy types - https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policy-types

AWS managed policies - https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies

AWS IAM Policies in a Nutshell - https://start.jcolemorrison.com/aws-iam-policies-in-a-nutshell/

Allow and Deny​

All permissions are implicitly denied by default. Thus, nothing is allowed unless there's an explicit Allow.

Any explicit Deny overrides any explicit Allows. Thus, if there's multiple policies with conflicting statements, the most restrictive policy is applied.

Note that the root user has full access.

Examples​

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html

AdministratorAccess policy​

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

Allows all actions on all resources.

Permissions policy and trust policy (role)​

See https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/

tip

Trust policy: who

Permissions policy: what

Permissions policy​

Defines the permissions (Allow or Deny) that the user of the role is able to perform (or is denied from performing), and on which resources. Is an identity-based policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:Describe*",
      "Resource": "*"
    }
  ]
}

Trust policy​

Who is allowed to assume the role, and under which conditions. Is a resource-based policy.

The IAM service supports only one type of resource-based policy called a role trust policy, which is attached to an IAM role. source

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

For example to allow the S3 service to replicate two buckets we create a Role with this custom trust policy:

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

Identity-based vs resource-based policy​

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html

Identity-based policy​

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_id-based

Attached to users, groups and roles (permissions policy). Can be attached in various ways:

  • Inline policy: a policy that only applies to single, specific user, group or role. It cannot be reused. If you delete the user, the policy is also deleted.
  • Managed policy: either created by you or AWS. Standalone: it can be applied to multiple entities.

Resource-based policy​

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based

Attached to a resource like an S3 bucket, a DynamoDB table or a SQS queue. Defines permissions for a principal accessing the resource.

Resource-based policies are inline policies. There are no managed resource-based policies. source

It has a Principal.

On the JSON there's a Principal who gets permission to perform Actions to a specific Resource only.

Not all resources support resource-based policies, see the table at https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html.

Example (source):

{
  "Version": "2012-10-17",
  "Id": "BucketPolicy",
  "Statement": [
    {
      "Sid": "AllAccess",
      "Action": "s3:*",
      "Effect": "Allow",
      "Principal": "*",
      "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"]
    }
  ]
}

Can be applied to a role too: a trust policy.

Note that when the Action applies to an object, like s3:GetObject, the Resource needs to have /* appended, otherwise the permission applies to the S3 bucket and it doesn't work:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPublicAccessToS3Objects",
      "Principal": "*",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-static-website-bucket/*" // <- We need '/*' here!
    }
  ]
}

Session policy​

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session

Limit the permissions of a role when you use the STS AssumeRole action using the CLI or API.

A session policy is a permissions policy which you can optionally pass during an AssumeRole operation. This enables you to place further restrictions on a role's permissions for that session. source

Generate policy based on CloudTrail events​

Automatically generates a policy for the permissions that the entity actually used.

Go to IAM → Roles and open a role. At the bottom you have the "Generate policy" button.

It's a recommended best practice

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_generate-policy.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html

Role vs Policy​

https://www.strongdm.com/blog/aws-iam-roles-vs-policies

A role is a type of IAM identity that can be authenticated and authorized to utilize an AWS resource, whereas a policy defines the permissions of the IAM identity.

https://www.learnaws.org/2022/03/03/iam-roles-policies/

https://repost.aws/questions/QUnIdoElwIRvWhJHjucPVkzg/what-are-the-key-differences-between-iam-roles-and-iam-policies

An role is very similar to a user, in that it is an identity with permission policies that determine what the identity can and cannot do in AWS. However, a role does not have any credentials (password or access keys) associated with it. Policies determine what actions a user, role, or member of a user group can perform, on which AWS resources, and under what conditions.

You attach IAM policies (which contain a set of permissions) to an IAM Role. Therefore, a single IAM roles can have multiple IAM policies in it. Lastly, a user can "assume" an IAM Role, meaning it will inherit automatically the policy or policies attached to that Role.

Principal​

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html

A Principal is a user, account, service, or other entity that is allowed or denied access to a resource source

It can be a (source):

  • AWS account and root user
  • IAM role
  • Role session
  • IAM user
  • Federated user session (Google, Facebook etc)
  • AWS service (ie an application)

Note that a Group is not a principal since:

You cannot identify a user group as a principal in a policy (such as a resource-based policy) because groups relate to permissions, not authentication, and principals are authenticated IAM entities source

A company with several departments that manage AWS​

https://explore.skillbuilder.aws/learn/course/120/play/459/introduction-to-aws-identity-and-access-management-iam

  1. Create an IAM group for each department.
  2. Create a policy and assign it to the group.
  3. Create IAM users for each person on each department and add them to their respective groups.

Finding your AWS account ID​

https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html#FindingYourAWSId

aws sts get-caller-identity

aws sts get-caller-identity --query Account --output text

Multi-factor authentication​

Supported MFA methods/devices - https://aws.amazon.com/iam/features/mfa/

Using multi-factor authentication (MFA) in AWS - https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html

Add MFA to other users​

(This works for yourself too if you are not the root user, since it doesn't appear on the list.)

Go to the IAM Dashboard → Users and select a user. Click the 'Security credentials' tab and do 'Assign MFA device'.

Enforce MFA to users​

Prevent users to perform actions unless they've set up MFA with a policy - https://www.youtube.com/watch?v=cP_IbgnK8yk - https://github.com/iaasacademy/aws-how-to-guide/tree/main/Enable%20IAM%20Users%20to%20setup%20MFA - https://iaasacademy.com/aws-how-to-guides/enable-iam-users-to-manage-their-mfa-settings-aws-how-to-guide/

Create the first IAM admin user​

We recommend that you not use the root level credentials for anything other than initial setup of the account and the creation of the IAM user account with administrator permissions attached via policy source

There are 2 guides/tutorials that explain how to set up the admin user:

Steps​

TLDR: create a group with the 'AdministratorAccess' policy, then create a user and add it to the group.

  • Sign in to the console as Root user.
  • Click your name at the top navbar → Account. At the section 'IAM User and Role Access to Billing Information' click 'Edit' and enable 'Activate IAM Access'.
  • Go to the IAM console → Users and click 'Create user'.
  • On the 'Set user details' page do:
    • Set 'User name' to 'Administrator'.
    • Check 'Provide user access to the AWS Management Console'.
    • Select 'I want to create an IAM user'.
    • Set a password at 'Custom password' and save it.
    • Uncheck 'Users must create a new password at next sign-in'.
    • Click 'Next'.
  • On the 'Set permissions' page do:
    • Click 'Add user to group' and then 'Create group'.
    • Set 'Group name' to 'Administrators'.
    • Check the policy 'AdministratorAccess'.
    • Click 'Create group'.
    • Click 'Next'.
  • On the 'Review and create' page optionally add tags.
    • Click 'Create user'.
Important

Don't forget to enable MFA for the admin user

Password policy​

Go to IAM → Account settings and on the Password policy box click the 'Edit' button.

https://www.netskope.com/blog/a-real-world-look-at-aws-best-practices-password-policies

ARN​

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html

Format:

arn:partition:service:region:account-id:resource-id
arn:partition:service:region:account-id:resource-type/resource-id
arn:partition:service:region:account-id:resource-type:resource-id

Examples:

# IAM user
arn:aws:iam::123456789012:user/johndoe
# VPC
arn:aws:ec2:us-east-1:123456789012:vpc/vpc-0e9801d129EXAMPLE

CLI​

aws iam list-users

aws iam list-users --profile <profile-name>

Create role

Example of trust policy document (trust.json):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<ACCOUNT_ID>:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Attach a Policy to a IAM role

Example of policy document iam-role-policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["eks:Describe*", "ssm:GetParameters"],
      "Resource": "*"
    }
  ]
}

Delete role

Permission boundaries​

Defines the maximum permissions that a user, group or role can have. Can be applied to users and roles. Used to prevent privilege escalation.

Sets the maximum permissions that an identity-based policy can grant an IAM entity.

Important: they don't grant permissions, it controls the permissions you have. You still need to have the permissions granted to you through a role for example.

(Documentation) Permissions boundaries for IAM entities - https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html

When and where to use IAM permissions boundaries - https://aws.amazon.com/blogs/security/when-and-where-to-use-iam-permissions-boundaries/

How can I use permissions boundaries to limit the scope of IAM users and roles, and also prevent privilege escalation? - https://aws.amazon.com/premiumsupport/knowledge-center/iam-permission-boundaries/

How can I resolve access denied issues caused by permissions boundaries? - https://aws.amazon.com/premiumsupport/knowledge-center/iam-access-denied-permissions-boundary/

Prevent privilege escalation with AWS IAM permission boundaries - https://iaasacademy.com/aws-how-to-guides/aws-iam-permissions-boundaries-help-to-prevent-privilege-escalations - https://www.youtube.com/watch?v=LZdfxS2DnFw

AWS Permission Boundaries for Dummies - https://news.ycombinator.com/item?id=33192295

It's a best practice - https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-permissions-boundaries

Eventually consistent​

From https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html

IAM, like many other AWS services, is eventually consistent. IAM achieves high availability by replicating data across multiple servers within Amazon's data centers around the world. If a request to change some data is successful, the change is committed and safely stored. However, the change must be replicated across IAM, which can take some time.

Changes that I make are not always immediately visible - https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency

www.it-automation.com/2021/06/06/how-to-deal-with-eventual-consistency-in-AWS-IAM.html