AWS IAM (Identity & Access Management)

Provides management of permissions for principals (an entity that can take an action on an AWS resource) in your environments

  • Principals include IAM users, IAM user groups, IAM roles, and third-party identity providers

  • Integrates with other AWS services

  • Uses federated identity management

  • Provides secure access for applications

  • Enables permissions to be controlled granularly

IAM Users

  • Reside within your account, not separate accounts

  • Have their own credentials (though not by default)

  • Have permissions granted to them or explicitly blocked from them

  • Can be replaced with users from identity providers, but they will need to be managed outside of AWS

IAM Policy

A group of permissions attached to either a resource or a principal is called an IAM policy.

There are two kinds of IAM policies:

Resource-based policy

  • Attached to AWS resources, such as Amazon DynamoDB tables or Amazon S3 Glacier archives

  • Control actions allowed by a specific principal and what conditions are required

  • Always inline (there are no managed resource-based policies)

  • Cannot attach policies to IAM identities even though they are technically AWS resources

Identity-based policy

  • Attached to users, groups, or roles

  • Control actions performed by what it’s attached to, including which resources and what conditions are required

  • Includes AWS-managed, customer-managed, and inline options for policies

  • Applications can have their own identities with their own sets of permissions

IAM Group

  • By placing IAM users into groups, you can manage their permissions as a group, rather than just individually.

  • Users and groups can each have their own policies attached.

  • You could group users by role, team, security level, or whatever factor makes the most sense.

  • When a user needs additional permissions (such as for a special project), you could either attach a new policy to their IAM user or move them into another IAM group, but the most efficient way to do this is with IAM roles.

IAM Roles

  • Like policies, they let you define a set of permissions.

  • Unlike policies, they are not attached to an IAM user or group. They are their own object.

  • Roles are assumed by the user or service that needs those permissions.

  • They are designed to easily attach or detach temporary permissions as needed without having to edit user or group policies repeatedly.

  • You can assume a role through the AWS Management Console, the AWS CLI, the AssumeRole API call, or AWS Security Token Service (AWS STS).

  • Use cases:

    • Providing AWS resources with access to other AWS services

    • Providing access to externally authenticated users

    • Providing access to third parties

    • Switching roles to access resources in:

      • Your AWS account

      • Any other AWS account (with cross-account access)