IAM Fundamentals

AWS IAM (Identity and Access Management) controls who can access which AWS resources. IAM is global and applies across all AWS services.

Users represent individual people or applications that need AWS access. Each user has a unique name within an AWS account and receives unique security credentials. For example, create separate IAM users for each developer rather than sharing a single root account. This provides individual accountability and audit trails.

Groups are collections of users that share the same permissions. Instead of attaching policies to each user individually, attach them to a group and add users to that group. For instance, a Developers group might have permissions to create EC2 instances and read S3 buckets, while an Administrators group has full access to all services.

Policies are JSON documents that define permissions. A policy specifies which actions are allowed or denied on which resources under which conditions. Policies can be attached to users, groups, or roles.

Managed Policies are AWS-managed or customer-managed policy documents that can be reused. AWS-managed policies like AdministratorAccess and ReadOnlyAccess provide common permission sets. Customer-managed policies give you full control over the permissions.

Inline Policies are embedded directly in a user, group, or role. Use inline policies for unique requirements that do not justify a reusable managed policy.

Best practice: Use groups to manage permissions. Assign users to groups, attach policies to groups, and avoid attaching policies directly to users whenever possible.

IAM distinguishes between two fundamental security concepts: authentication and authorization.

Authentication verifies identity. When you sign in to the AWS Management Console with a username and password, you authenticate. When you use access keys with the AWS CLI, you authenticate. MFA (Multi-Factor Authentication) strengthens authentication by requiring a second factor like a hardware token or virtual authenticator app.

Authorization determines what an authenticated identity can do. After you authenticate as an IAM user, authorization checks whether your policies allow the requested action. For example, you might authenticate successfully but be denied access to delete an S3 bucket if your policy does not include s3:DeleteBucket.

This separation is critical for security. Authentication without proper authorization means compromised credentials have full access. Strong authentication combined with least-privilege authorization minimizes the blast radius of security incidents.

Root Account credentials have unrestricted access to everything. AWS strongly recommends securing the root account with MFA, avoiding daily use, and creating IAM users for all access. A compromised root account means complete account compromise.

IAM Identity Center (formerly AWS SSO) provides centralized authentication for multiple AWS accounts and business applications. Users authenticate once and access assigned accounts without separate credentials.

Multi-Factor Authentication (MFA) adds a second layer of security beyond passwords. When enabled, users must provide a password plus a one-time code from a hardware token, virtual authenticator app (like Google Authenticator), or SMS. MFA protects against credential theft and phishing attacks.

Enable MFA for all users, especially those with elevated permissions. The root account must have MFA enabled as a baseline security requirement.

Console Access is granted through IAM user credentials (username and password). Users sign in at the AWS Management Console URL using their account ID or alias. Console access is appropriate for users who need a visual interface for management tasks.

Programmatic Access uses access keys (access key ID and secret access key) for CLI, SDK, and API calls. Access keys are long-term credentials that can be rotated. For example, a CI/CD pipeline uses access keys to deploy infrastructure via Terraform or CloudFormation.

Security Best Practices:

• Rotate access keys every 90 days
• Use IAM roles instead of access keys for EC2 instances and Lambda functions
• Store access keys in AWS Secrets Manager or a secure vault, never in code
• Enable CloudTrail to log all API calls for audit purposes
• Use permission boundaries to limit the maximum permissions an IAM user or role can have

The principle of least privilege means granting only the minimum permissions required to perform a specific task. This is the most fundamental IAM security principle.

For example, a Lambda function that reads items from a DynamoDB table should have a policy allowing only dynamodb:GetItem and dynamodb:Query on that specific table, not dynamodb:* on all tables. This limits the damage if the Lambda function is compromised.

Implementation Steps:

1. Identify the exact actions required for each role or user
2. Create policies with the minimum necessary actions and specific resource ARNs
3. Use IAM Access Analyzer to identify unused permissions and overly permissive policies
4. Review policies regularly and remove permissions no longer needed

Permission Boundaries set the maximum permissions an IAM entity can have, even if its policies grant broader access. For example, set a boundary that limits a developer to only EC2 and S3 services. Even if someone attaches an AdministratorAccess policy, the boundary prevents access to other services.

Resource-Based Policies are attached directly to resources (like S3 bucket policies or Lambda resource policies). They specify who can access the resource and what they can do. Unlike identity-based policies, resource-based policies grant cross-account access by specifying AWS accounts or ARNs in the principal field.

A common mistake is starting with broad permissions and narrowing later. Start with minimal permissions and add only what is needed. Use AWS CloudTrail and IAM Access Analyzer to identify required permissions through actual usage patterns.