> For the complete documentation index, see [llms.txt](https://mamawhocode.gitbook.io/aws/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mamawhocode.gitbook.io/aws/services/access-management/iam.md).

# IAM

Identity and Access Management

## Overview

### IAM

* Free global service.
* Help you `manage access` to services, and resources.
* IAM entities:

  * **IAM Groups**: contain users
  * **IAM Users**: a person, or service
  * **IAM Federated users**: Amazon, Facebook, Google, Twitter users.
  * **IAM Roles**:

    `temporary` permission to interact with resources. 

    * A role do not have long-term credentials. 
    * It has 1-many relationship with users or applications.
    * Cross account access in different environment. Ex: Same user want to access both dev and prod environment. So by assume different role, that user can access prod without creating new identity.

  <figure><img src="https://2259236002-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fuh9xZDZ53qGqmMCM44PU%2Fuploads%2Fgit-blob-6429ddba8104b9724bdc27a3ddca0b34bf2829a6%2FIAM_20220918162005.png?alt=media" alt=""><figcaption><p>How a service assume role</p></figcaption></figure>

### IAM policy

* `JSON document` used to define <mark style="color:red;background-color:orange;">**ALLOW/DENY**</mark> permissions.
* There are 3 types of policies: AWS managed, inline and Customer managed.

#### AWS access levels

<figure><img src="https://2259236002-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fuh9xZDZ53qGqmMCM44PU%2Fuploads%2Ftr0HlLgWGMbnZnsYw428%2Fimage.png?alt=media&amp;token=a3c09cde-df4f-4bf9-b373-6753572cf4c7" alt="" width="360"><figcaption><p>AWS services's actions</p></figcaption></figure>

#### Syntax

* In JSON policy, a statement consist of **EAR** (basic structure)
  * <mark style="color:red;">**E**</mark>**ffect**: ALLOW or DENY
  * <mark style="color:red;">**A**</mark>**ction**: Get, Put, Write...
  * <mark style="color:red;">**R**</mark>**esource**&#x20;
  * **Principal**: AWS account/user/role to `which` the policy apply to.
  * **Conditional** (optional): `when` this policy effect.
* IAM policy example

  ![](https://rxhl.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fc48e7906-339a-4dbc-8dbe-17030c5a0314%2FScreen_Shot_2020-09-13_at_1.52.27_PM.png?table=block\&id=8a9f841f-90a6-4bc0-864f-169770629607\&spaceId=b3a9e1c5-c540-47ac-82b3-9b6937f151ed\&width=740\&userId=\&cache=v2)

  * **Can you create a SQS queue?**
    * No because there's an explicit deny.
  * **Can you delete a SQS queue?**
    * No because there's an explicit deny for all actions relate to [SQS](/aws/services/integration/sqs.md).
  * **Can you create an EC2 instance?**
    * There's no explicit deny or allow. Since everything in AWS is deny by default so no.

### IAM provision workflow

![common workflow](https://2259236002-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fuh9xZDZ53qGqmMCM44PU%2Fuploads%2Fgit-blob-59bcacceb8e4a6b44bdcd45cc770b7f66945304a%2FIAM_20220918135029.png?alt=media)

### Other policies

#### **4 types of policy**

* Identity-based
* Resource-based
* Organization SCPs
* Access control lists (ACLs)
  * If has 1 or more DENY, than the result is DENY
  * If nobody is ALLOW, then the result is also DENY.

#### **IAM Roles vs Resource-based policies**

* When you *assume role*, you give up original permission of your principal and take the new ones given by the role.
* When using resouce-based policy, you DON'T have to give up permission of your principal.&#x20;

  <figure><img src="https://rxhl.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F1dcae02c-f122-4fd7-abbf-832bec25d5e1%2FScreen_Shot_2020-09-13_at_1.39.13_PM.png?table=block&#x26;id=8699952e-0f0d-4582-b47c-9dc7bffc3310&#x26;spaceId=b3a9e1c5-c540-47ac-82b3-9b6937f151ed&#x26;width=1780&#x26;userId=&#x26;cache=v2" alt=""><figcaption><p>IAM role &#x26; Resource-based policies</p></figcaption></figure>

***

## Features

### Permission boundary

* The `maximum` permission that you can grant to an IAM entity.

### Policy evaluation logic

![IAM policy evalution logic flow](https://docs.aws.amazon.com/images/IAM/latest/UserGuide/images/PolicyEvaluationHorizontal111621.png)

### IAM Access Analysis

#### Benefits

* Quickly analyze thousands of resource policies
* Continuously monitors and helps you refine permissions
* Provides the highest levels of security assurance
  * identify which resources grant public or cross-account access.

#### How it works?

1. **Step1**: Create an analyzer -> continuously scans the policies.
2. **Step2**: Review your findings
3. **Step3**: Take action: modify the policy.

### IAM credentials report

List all your IAM users and status of their various credentials.

***

## Use cases

* Grant permissions, create users, groups or roles in the tenant
* Manage per-account access, or multi-account access (IAM Identity Center)
* Verify right-size permission (least priviledge principle)
* Control how user access AWS
  * Using SSL?
  * Which IP address?
  * Time of day
  * Authenticated user only
  * Multi-factor authentication device.
* Integrate with corporate directory

<figure><img src="https://2259236002-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fuh9xZDZ53qGqmMCM44PU%2Fuploads%2FJB8ppYX6oLrEuYdBPq3n%2Fimage.png?alt=media&amp;token=3c14a189-f857-4b44-a678-263df89a8fb4" alt="" width="286"><figcaption><p>grant employees access to AWS resources</p></figcaption></figure>

***

## Best practices

### Top-10 security items to improve your AWS account

![](https://d2908q01vomqb2.cloudfront.net/22d200f8670dbdb3e253a90eee5098477c95c23d/2020/03/19/10-Security-Itemsb-Figure-1.png)

### Security [best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)

* Using temporary credentials
* Use MFG
* Rotate access keys
* Don't user root account for anything except Billing
* Apply [least-privilege principle](/aws/knowledge/aws-best-practices/least-privilege_principle.md)
* Use IAM Access Analyzer to generate least-privilege policies based on access activity
* Regularly review and remove `unused` users, roles, permissions, policies, and credentials
* Use permissions boundaries: set maximum permissions

***

## Trivia

* IAM user and IAM group are for people. `IAM Roles` are for machines and services.
* Groups cannot belong to other groups. `NO nesting`.
* **CANNOT** **add** <mark style="color:red;">**role**</mark>**&#x20;to a&#x20;**<mark style="color:red;">**group**</mark>. *Only users* and *services* can assume a role to take on permissions.&#x20;
* If you want to manage `multiple AWS account`, use [IAM Identity Center](/aws/services/access-management/iam_identitycenter.md) (AWS SSO)
* BY **DEFAULT**, all request are <mark style="color:red;">**denied**</mark>.&#x20;

  * Explicit ALLOW grant permissions.&#x20;
  * Explicit DENY overwrite any ALLOW.

  →IAM policy evaluation is not sequential. AWS evaluates all applicable policies and applies the *most restrictive rule*.
* Add condition key `aws:PrincipalOrgID` to resource-based policy if you want to allow all AWS accounts from the organization to access that resource.