Identity and Access Management (IAM) provides the centralized management of your AWS account. It manages who can access what in your AWS services. Access control is done via policies that can be attached to users, groups, and roles.
- IAM is a global service that is not tied to a region.
- Users and policies can be used globally.
- Users are given long-term credentials to access AWS resources (username/password or access keys).
- Roles allow for short-term access to resources when assumed, using temporary access credentials.
- IAM can work with Identity Federation such as Active Directory or Web Identity Federation (Facebook, Google, etc.)
Terminologies
- Users – people or applications that access AWS resources
- Groups – a collection of users that share a set of permissions
- Roles – a way to grant permissions to trusted entities
- Policies – a document that defines one or more permissions
Accounts
- Root account
- has full administrative permissions
- should not be used for daily work
- Create a separate IAM user (with least privilege)
- Create a admin group with proper permissions, create user accounts and add them to the admin group
- needs to be protected with MFA (Multi-Factor Authentication)
- A newly created IAM user has NO access to any AWS Services (implicit DENY)
- Necessary permissions need to be granted to a new user directly or via groups.
Accessing AWS Platform
- Via the AWS Console: All actions in the console are API calls.
- Using the AWS CLI (Command Line Interface): text-based command interface through API calls
- Using the AWS SDK (Software Developers Kit): support many programming languages
Best Practices
- Best IAM Security Best Practices
- Never use your root account for day-to-day use
- Grant least privilege access for IAM users
- Enable Identity federation and use AWS single sign-on
- Enable MFA
- Rotate credentials regularly
- Enable IAM Access Analyzer
- Account Security Best Practices
- Delete root user access keys
- Activate MFA for a root account
- Create individual IAM users
- The principle of least privilege: Users should only have enough permissions to do their job, and nothing more.
- Do not assign permission directly to users. Instead, use groups to inherit permissions.
- Apply IAM password policies
Cross-Account Access
- It allows IAM users in one account to access resource that are in different AWS accounts.
- Cross-account access is handled through the use of IAM roles
- No need to create individual IAM users in each account, do not need to use multiple IAM user accounts.
Policies
- Policies are assigned to users and groups to grant access to AWS resources.
- Policy documents are written in JSON.
Users
- IAM users are a type of IAM identity suitable for long-term access for a known entity (human, service, or an application).
- Hard limit of 5,000 IAM users per account; 10 groups per IAM user; 10 managed policies per user (default).
- By default, an IAM user does not have any access to AWS resources. Permissions need to be assigned explicitly – directly or via groups.
- No inline policy limit – you cannot exceed 2048 characters for all inline policies on an IAM user.
- 1 MFA (Multi-Factor Authentication) per user
- 2 Access keys per user.
- User credentials should never be passed or stored to EC2 instances. Use roles instead.
Groups
- An IAM group is a collection of IAM users under one set of permissions.
- Groups allow easier administration over sets of IAM users. Inline and managed policies can be applied to groups that flow on to members of that group.
- Groups can contain many IAM users, and users can be in many groups (up to 10).
- Groups have no credentials.
Access Keys
- Access Keys are a pair of values that are used to authenticate to AWS (by CLI or SDKs)
- Access Key ID: the public part of the key and is stored by AWS
- Secrete Access Key: the private part of the key, available only once when the key is created.
- An IAM user is the only identity that uses the access keys.
- Two sets of access keys are allowed. They can be created, deleted, enabled, and disabled.
- Access keys cannot be used to log in to the console, and they do not expire.
Roles
You can create a role with a set of permissions. And then you let authenticated users assume the role to access the resources temporarily.
- IAM roles are assumed by another identity allowed in the trust policy.
- Roles cannot be used to log into AWS Services.
- When a role is assumed, the Security Token Service (STS) generates a time-limited set of access keys.
- Roles use sts:AssumeRole by another identity: IAM users, AWS services, External accounts, or Web Identities.
- The temporary access keys (security credentials) have the permission defined in the Permission Policies.
Example: an EC2 instance needs to access an S3 bucket
- An EC2 instance assumes a role with proper S3 access permissions.
- Any credential should not be stored in an EC2 instance.
- An EC2 instance can only have one role attached at a time.
- A role can be changed after the creation of an instance.
Roles with AWS Services
- Roles must be used with AWS Services because policies cannot be directly attached to AWS services.
- Only one role can be attached to a service at a time.
Use Cases of a Role
- Company Merger
- AWS Service Access
- “Break-glass” style extra access
- Cross-Account Access
- Identity Federation
- Non-AWS users can assume temporary roles to access AWS resources.
- Active Directory
- Single Sign-On (SSO) providers, such as Facebook or Google
IAM Security Tools
- IAM Credentials Report (account-level)
- lists all account users and the status of their credentials (passwords and access keys)
- csv format
- IAM Access Advisor (user-level)
- shows service permissions and when those services were last accessed
Scriptorium 