# AWS Identity & Access Management (IAM) Fundamentals ##
## **What is AWS IAM?** AWS Identity & Access Management (IAM) is the foundation of **secure access control** in AWS. It manages **who** can access AWS resources, **what** they can do, and **how** access is granted. ### **Key IAM Features** * User authentication & authorization * Granular access controls with policies * Role-based access management (RBAC) * Temporary security credentials for workloads * Integration with Identity Providers (Okta, Azure AD, etc.) ### **How SecureCart Uses IAM** SecureCart uses IAM to **control access to AWS services and resources** while following **security best practices** to protect customer data, prevent unauthorized changes, and enable seamless operations. ### Examples * Developers need to manage deployments but should NOT have full admin access. * SecureCart’s EC2 instances need to retrieve product images from S3 without storing credentials. * A Lambda Function Needs to Process Payments Using AWS Secrets Manager * SecureCart’s CI/CD Pipeline in the `DevOps` Account Needs to Deploy to `Production` * SecureCart’s security engineers should be able to audit AWS resources but NOT make changes. | **Scenario** | **IAM Solution** | | ------------------------------------------------- | ----------------------------------------------------- | | **Developer Access to AWS Accounts** | IAM Identity Center (SSO) with Permission Sets | | **EC2 Access to S3 for Product Images** | IAM Role assigned to EC2 instance | | **Lambda Access to Secrets Manager for Payments** | IAM Role with Secrets Manager read access | | **CI/CD Deployment Across Accounts** | Cross-account IAM Role assumption | | **Security Team Read-Only Audits** | IAM Identity Center Group with `SecurityAudit` policy | *** ## **IAM Users** * IAM Users represent individuals who need access to AWS. * Each IAM User has unique credentials (password, access keys, MFA) and can have assigned permissions. ### **How SecureCart Uses IAM Users** * Only used for break-glass access (not for daily work). * SecureCart relies on IAM Identity Center (SSO) instead of IAM Users for authentication. * MFA is required for any IAM User with AWS Management Console access. *** ## **IAM Groups** * IAM Groups combine multiple IAM Users and assign permissions to them collectively. * Instead of assigning policies one by one, a group policy applies to all users inside the group. ### **How SecureCart Uses IAM Groups** * SecureCart avoids IAM Groups in favor of IAM Identity Center (SSO). * If IAM Groups were needed, SecureCart would create * `Billing-ReadOnly` (Finance Team) * `Security-Audit` (Security Team) * `DevOps-Admin` (Operations Team) *** ## **IAM Policies** * IAM Policies define permissions for users, groups, or roles. * They specify who can do what on which resources. ### **Types of IAM Policies** * AWS-Managed Policies → Predefined by AWS (e.g., `AdministratorAccess`, `ReadOnlyAccess`). * Customer-Managed Policies → Custom policies SecureCart creates for fine-grained control. * Inline Policies → Directly attached to users, groups, or roles (not reusable). ### **How SecureCart Uses IAM Policies** * Least privilege (Only allow necessary actions). * Deny dangerous actions like deleting databases. * Use AWS-Managed Policies for standard use cases. *** ## **IAM Roles** * IAM Roles provide temporary permissions to users, AWS services, or applications. * Unlike IAM Users, IAM Roles do not have permanent credentials. ### **IAM Role Use Cases** * Applications running on EC2, Lambda, or ECS that need access to AWS services. * Cross-account access between different AWS accounts. * Temporary security credentials for users via AWS STS. ### **How SecureCart Uses IAM Roles** * SecureCart EC2 instances assume IAM Roles to access S3 securely. * Developers assume IAM Roles instead of using IAM Users. * Cross-account roles allow CI/CD to deploy across multiple AWS accounts. *** ## **AWS Security Best Practices for IAM** * Use IAM Identity Center (SSO) instead of IAM Users * Require MFA for all human access * Use IAM Roles instead of long-term IAM credentials * Follow the principle of least privilege in IAM Policies * Enable IAM Access Analyzer to detect misconfigurations * Use AWS CloudTrail to log IAM activity