AWS IAM provides authentication and authorisation for AWS resources.
AWS uses two types of accounts:
- The Root Account can do everything, and their use is discouraged.
- Sub-accounts allow delegating access to resources within the Root Account to other users.
It's possible, though discouraged, to login with the root account which can perform all operations, so it's advisable to create sub-accounts to use for day-to-day administration.
IAM manages access through:
- Users, who can authenticate with the service.
- Groups into which users are placed.
- Roles are authentication methods for users. They're associated with policies linked to AWS resources. Users are able to switch between roles, allowing for project-level or tiered access controls to reduce blast radius.
- Policies, which allow members of a group to assume Roles, and Roles to perform actions against Resources.
IAM policies are comprised of the following properties:
Sidis an identifier.
Effectis the action to take, either
Actionspecifies the permitted/denied actions.
NotActionallows matching everything but the selected operations.
Resourceis a string matching ARNs.
Conditionallows matching global or service-specific condition keys against an operator and one or more operands.
Actions can be expressed in list or string form and entries may use globs to match multiple rules.
The Security Tokens Service allows obtaining temporary (15 minutes through a day and a half) security credentials for IAM users. This allows shedding permissions for use in automation processes and temporarily increasing the level of access when necessary to administrate resources.
Enterprise Identity Federation allows authentication users on the owning organisation's network with no need to create AWS identities and manage separate credentials. Web Identity Federation allows authenticating users via a third-party OpenID Connect identity provider, negating the need for separate credentials.
Trust relationships across accounts allow users from one account to log in and perform operations in another, e.g. for accessing AWS Organisation member accounts.
Instance profiles pass IAM roles to EC2 instances, helping you avoid credential management and storage.
PassRole permission determines which roles a given role may attach to instances, solving the confused deputy problem.