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.

  

  How a service assume role

IAM policy

• JSON document used to define ALLOW/DENY permissions.

• There are 3 types of policies: AWS managed, inline and Customer managed.

AWS access levels

AWS services's actions

Syntax

• In JSON policy, a statement consist of EAR (basic structure)

  • Effect: ALLOW or DENY

  • Action: Get, Put, Write...

  • Resource

  • Principal: AWS account/user/role to which the policy apply to.

  • Conditional (optional): when this policy effect.

• IAM policy example

  

  • 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 on top which precedes the allow.

  • 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

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.

  

  IAM role & Resource-based policies

---

Features

Permission boundary

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

Policy evaluation logic

IAM policy evalution logic flow

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

grant employees access to AWS resources

---

Best practices

Top-10 security items to improve your AWS account

Security best practices

• Using temporary credentials

• Use MFG

• Rotate access keys

• Don't user root account for anything except Billing

• Apply least-privilege principle

• 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 role to a group. Only users and services can assume a role to take on permissions.

• If you want to manage multiple AWS account, use IAM Identity Center (AWS SSO)

• IAM policy process in top-down order. If there a DENY above an ALLOW statement for the same permission, the ALLOW statement does not processed -> In IAM policies, an explicit "Deny" overrides an "Allow".

• Add condition key aws:PrincipalOrgID to resource-based policy if you want to allow all AWS accounts from the organization to access that resource.