# IAM Fundamentals

## **Overview**&#x20;

AWS **Identity and Access Management (IAM)** is a core service that helps you **securely manage access to AWS services and resources**. It provides the tools to **create users, roles, and policies** and assign them specific permissions to AWS resources, ensuring **fine-grained control** over who can access what. Below are the essential concepts you need to understand to get started with AWS IAM.

### **Key Concepts in AWS IAM**

1. **IAM Users**
2. **IAM Groups**
3. **IAM Roles**
4. **Policies**
5. **Permissions and Policy Evaluation Logic**
6. **Access Keys and MFA**
7. **Federation with External Identity Providers**
8. **Best Practices for IAM**

#### 1. **IAM Users**

* An **IAM user** is an **entity that represents an individual** who needs access to AWS resources.
* A user is created within your AWS account and has **credentials** (password or access keys) for interacting with AWS.
* IAM users are used when **permanent credentials** are required, such as for developers accessing the AWS Management Console or CLI.

**Example Use Case:**\
A DevOps engineer logs into the AWS Console with their IAM credentials to manage EC2 instances.

#### 2. **IAM Groups**

* An **IAM group** is a collection of users that share the same permissions.
* **Groups simplify administration** by allowing you to assign policies to a group, which are automatically inherited by all the users in that group.

**Example:**

* Create a `Developers` group and assign it permissions to interact with EC2 and S3 services.
* Add individual users to the group, and they will inherit the group’s permissions.

#### 3. **IAM Roles**

* An **IAM role** is an identity that can be **assumed by a trusted entity** for temporary access to resources.
* Roles are preferred when you don't want to store long-term credentials in your code or services.
* Roles can be assumed by **users, applications, AWS services (like EC2 or Lambda), or other AWS accounts**.

**Example Use Case:**\
An EC2 instance assumes a role to access an S3 bucket without storing access keys in the instance.

#### 4. **Policies**

* **Policies** are JSON documents that define **permissions**. They specify **who can perform what actions** on which resources.
* AWS IAM supports two types of policies:
  1. **Managed Policies**: Predefined by AWS or reusable across users, groups, and roles.
  2. **Inline Policies**: Attached directly to a single user, group, or role for specific use cases.

**Example Policy:** This policy allows a user to read objects from an S3 bucket.

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}
```

#### 5. **Permissions and Policy Evaluation Logic**

When a request is made in AWS, IAM evaluates all attached **policies** to determine whether the request is allowed or denied. Here’s the key logic:

1. **Explicit Deny**: If any policy denies the action, the request is denied.
2. **Explicit Allow**: If no explicit deny exists and at least one policy allows the action, the request is allowed.
3. **Implicit Deny**: If there is no policy allowing the action, it is denied by default.

**Example:**\
If a policy allows access to an S3 bucket, but another policy explicitly denies it, the access is denied.

#### 6. **Access Keys and MFA (Multi-Factor Authentication)**

* **Access keys** are used for programmatic access (e.g., AWS CLI or SDK) and consist of an **Access Key ID** and **Secret Access Key**.
* **Multi-Factor Authentication (MFA)** adds an extra layer of security by requiring a second authentication factor (like an OTP from an authenticator app).

**Example Use Case:**\
Developers use access keys to interact with AWS services from their local CLI and are required to authenticate with MFA to access the AWS Management Console.

#### 7. **Federation with External Identity Providers**

* IAM supports **federation** with external identity providers (IdPs) using **SAML 2.0** or **OIDC** protocols.
* This allows users to **log in to AWS using credentials from third-party services** such as Microsoft Active Directory, Google Workspace, or Okta.

**Example Use Case:**\
A company’s employees log in to AWS using their corporate credentials managed by Active Directory, without needing dedicated IAM user accounts.

#### 8. **Best Practices for IAM**

1. **Use Roles Instead of Users**:
   * Assign roles to services and applications to avoid using long-term credentials.
2. **Follow the Principle of Least Privilege**:
   * Grant only the permissions required to perform specific tasks.
3. **Enable MFA for Privileged Accounts**:
   * Secure the root account and critical IAM users with MFA.
4. **Use Groups to Assign Permissions**:
   * Instead of managing permissions for individual users, use groups.
5. **Rotate Access Keys Regularly**:
   * Avoid keeping the same access keys indefinitely to minimize risk.
6. **Monitor and Audit IAM Activity**:
   * Use **AWS CloudTrail** to track changes in IAM permissions and detect suspicious activity.

### **Example IAM Workflow**

Let’s walk through a scenario to see IAM in action:

1. **Create a Role for EC2 Access to S3**:
   * Create an IAM role named `EC2S3AccessRole`.
   * Attach a policy to the role that allows `s3:GetObject`.
2. **Assign the Role to an EC2 Instance**:
   * Launch an EC2 instance and assign the `EC2S3AccessRole` to it.
3. **Test Access from the EC2 Instance**:
   * SSH into the EC2 instance.
   *   Use the AWS CLI to access the S3 bucket:

       ```bash
       aws s3 ls s3://example-bucket/
       ```
   * The EC2 instance is able to list the contents of the bucket without any hard-coded credentials.
