AWS IAM is the main Security, Identity & compliance service, make sure you know as much as you can about it with this cheat sheet.
The IAM infrastructure:
- A principal is an IAM entity that is allowed to interact with AWS resources.
- A principal can be permanent or temporary.
- can represent a human or an application.
- There are three types of principals: root users, IAM users, and roles/temporary security tokens:
- A principal that has complete access to all AWS Cloud services and resources in the account.
- root user is a permanent principal.
- it has full privileges to do anything in the account, including closing the account.
- It is strongly recommended that you do not use the root user for your everyday tasks, instead use it to create your first IAM user.
- should be secured with multi-factor authentication (MFA).
- Users are persistent identities that represent individual people or applications.
- IAM users are not separate accounts; they are users within your account
- When creating a user’s credentials, you can only see/download the credentials at the time of creation not after.
- By default when you create a user, he has NO permissions to do anything.
- you don’t have to create separate IAM users for existed corporate users. Instead, you can federate those user identities into AWS.
Roles / Temporary Security Tokens:
- Roles are used to grant specific privileges to specific actors for a set duration of time.
- Each role has 2 policies:
- Permission policy: going to define what the role can or can not do.
- Trust Policy: define who/what can assume the role (principal).
- When one of the actors assumes a role, AWS provides the actor with a temporary security token from the AWS Security Token Service (STS) that the actor can use to access AWS cloud services.
- The range of a temporary security token lifetime is 15 minutes to 36 hours.
- when and IAM role is assumed, temporary permissions based on the policy attached to that role are granted, and the permissions granted to the IAM user account are temporarily removed
- Using IAM roles for Amazon EC2 removes the need to store AWS credentials in a configuration file.
- the principal sends a request to AWS whenever it tries to use the AWS Management Console, the AWS API, or the AWS CLI.
Three ways that IAM authenticates a principal:
used when a principal is human, a user name and password will verify the identity.
When a program is manipulating the AWS infrastructure via the API it will use an access key (a combination of access key ID and access secret key).
Access Key/Session Token:
Authentication using a Temporary Session Token (Access key+Session Token) When an IAM user is operating under an assumed role. Calls to AWS must include both the two-part access key and the session token to authenticate
- Authorization is the process of specifying exactly what actions a principal can and cannot perform.
- Authorization is handled in IAM by defining specific privileges in policies and associating those policies with principals
- A policy is a JSON document that fully defines a set of permissions to access and manipulate AWS resources.
- Policies can be applied to users, groups, and roles.
- Policy documents contain one or more permissions, with each permission defining:
- Effect: “Allow” or “deny”.
- Service: for what service does the permission apply.
- Resource: The resource value specifies the specific AWS infrastructure for which this permission applies specified with ARN (ex: Amazon S3 Bucket – arn:aws:s3:us-east-1:123456789012:my_corporate_bucket/*).
- Action: The action value specifies the subset of actions within a service that the permission allows or denies.
- Condition: The condition value optionally defines one or more additional restrictions that limit the actions allowed by the permission.
- policy can be associated directly with an IAM user in one of four ways:
- User Policy: a user policy is entered into the user interface on the IAM user page.
- Managed Policies: those are predefined policies writing by AWS. Using predefined managed policies ensures that when new permissions are added for new features, your users will still have the correct access.
- IAM groups: After a policy is assigned to a group, any user who is a member of that group assumes those permissions.
- Assuming a role: After an actor has assumed a role, it is provided with a temporary security token associated with the policies of that role.
- There are two ways a policy can be associated with an IAM group:
- Group Policy: These policies exist only in the context of the group to which they are attached.
- Managed Policies: Managed policies that are created and managed by AWS that can be associated with groups.
- some services (S3, SQS…) support resource-based permissions which let you attach policies to the service’s resources instead of users or groups.
- The action value specifies the subset of actions within a service that the permission allows or denies.
- A resource is an object that exists within a service. Examples include an Amazon EC2 instance, an IAM user, and an Amazon S3 bucket.
- grant access to AWS resources to IAM users in other AWS accounts.
- You can set up an IAM role with the permissions you want to grant to users in the other account.
- recommended as a best practice, as opposed to distributing access keys outside your organization.
- IAM Identity Providers provide the ability to federate outside identities with IAM and assign privileges to those users authenticated outside of IAM.
- IAM can integrate with two different types of outside Identity Providers (IdP):
- integration via OpenID Connect (OIDC): For federating web identities such as Facebook, Google, or Login with Amazon.
- integration via Security Assertion Markup Language 2.0 (SAML): For federating internal identities, such as Active Directory or LDAP.
- federation works by returning a temporary token associated with a role to the IdP for the authenticated identity to use for calls to the AWS API.
Multi-Factor Authentication (MFA):
- Multi-Factor Authentication (MFA) adds an extra layer of security to your infrastructure by adding a second method of authentication beyond just a password or access key.
- MFA requires you to verify your identity with both something you (password) know and something you have (can be your phone).
- MFA can be assigned to any IAM user account, whether the account represents a person or application.
- It is strongly recommended that AWS customers add MFA protection to their root user.
- The MFA device can be either a small hardware device you carry with you or a virtual device via an app on your smartphone.
- the default maximum number of MFA devices in use per AWS account at the root account level is 1.
- To protect your AWS infrastructure, access keys should be rotated regularly.
- AWS allows two access keys to be valid simultaneously to make the rotation process straightforward: Generate a new access key, configure your application to use the new access key, test, disable the original access key, test, delete the original access key, and test again.
IAM is offered at no additional charge.
Best Practices for Securing the AWS Account.
How to secure your AWS account (Best practices):
- Do not share root credentials with anyone other than the account holder.
- Enable MFA for root-level access.
- Secure (physically) the root MFA devices in a safe place.
- Create individual IAM users.
- Remove root credentials.
- Enbale MFA for privilliged users.
- Use groups to assign permissions to IAM users.
- Use IAM roles for applications that run on Amazon EC2 instances.
- Delegate by using IAM roles instead of sharing credentials.
- Remove unnecessary credentials.
- Rotate credentials regularly.
- Use policy conditions for extra security.
- Use access levels to review IAM permissions.
- Use AWS-defined policies to assign permissions whenever possible.
- Use IAM roles to provide cross-account access.
- Monitor activity on your account.
IAM video from AWS
IAM practice questions:
Notice: we keep updating this material
AWSBOY Cheat sheets
You can report a mistake or suggest new points to add in this IAM cheat sheet… let us know in the comment section!