IAM

4.1.1. Introduction

AWS Identity and Access Management (IAM) is a crucial service that allows users to manage identities and control access to AWS services and resources securely. Rather than maintaining multiple credentials, IAM employs roles and policies that enable fine-grained permission assignments, applicable not just to users but also to resources.

The importance of IAM as part of AWS security cannot be overstated; it ensures that only authorized users gain access to resources, eliminating the potential for security flaws that can be challenging to correct later.

Despite its user-friendly start, mastering IAM involves navigating through a comprehensive range of features, emphasizing the need for deeper understanding and expertise.

4.1.2. Amazon Resource Identifiers: How Resources Are Identified in a Uniquely Manner

To effectively utilize AWS IAM, one must comprehend how resources are uniquely identified through Amazon Resource Identifiers (ARNs). Each ARN consists of several key components:

arn:<partition>:<service>:<region>:<account-id>:<resource-id>

Examples of ARNs include:

• Amazon S3 Bucket: arn:aws:s3:::my-bucket

• Amazon EC2 Instance: arn:aws:ec2:eu-west-1:123456789012:instance/i-01234567890abcdef

• Amazon RDS Database: arn:aws:rds:eu-west-1:123456789012:db:mydatabase

• Amazon DynamoDB Table: arn:aws:dynamodb:eu-west-1:123456789012:table/mytable

The components are broken down as follows:

• Resource Type: This indicates the type of resource (e.g., S3, EC2, RDS, DynamoDB).

• Region: Specifies the AWS region in which the resource is located (e.g., us-east-1).

• Account ID: A unique identifier for the AWS account that owns the resource (e.g., 123456789012).

Some services like S3 may not be bound to a single region; hence their region identifier might be omitted.

The unique identifiers enable the specification and authorization of access to resources in a secure and standardized manner, applicable across various AWS contexts such as CloudFormation templates and service APIs.

4.1.3. Users, Roles, and Groups Are the Three Important Identity Concepts

In AWS IAM, identities are the core concept representing a user that can access resources within an AWS account. Each identity can receive one or more policies which dictate the permissions granted for resources. Such identities also include groups, which help in user management via collective policy assignments, and roles, which can be assumed by users or other AWS services.

4.1.3.1. User: A Person or Service That Interacts with One or Several AWS Accounts

Users are defined as identities that can interact with AWS and its APIs. Each user has a name, credentials, and designated AWS access types, typically categorized into:

• Access Key ID

• Secret Access Key

• AWS API

• AWS Console

Users can be integrated via either programmatic access (using access keys) or console access (using passwords).

4.1.3.2. Group: A Collection of Users to Easily Manage Several Users

In instances where many users exist within an AWS account, managing permissions on an individual basis can become impractical. Thus, grouping users according to their job functions simplifies permission management.

For example:

• Administrators: Manage user permissions; full access rights.

• Developers: Access to create and manage AWS resources for application development.

• Quality Assurance: Permissions for delivery pipeline, database, and reports access.

• Business Analysts: Access to production data for insights.

Users can belong to multiple groups, thus inheriting combined permissions based on their group memberships.

4.1.3.3. Role: An Identity with a Permission Set That Can Be Assumed

Roles function similarly to users, in that they define a set of permissions; however, they are not tied to a singular identity. Roles can be adopted by any service or individual that requires them, commonly employed by AWS service principals (e.g., Lambda functions or ECS container agents).

4.1.3.4. Issuing Temporary Credentials to Enforce Time-Limited Access

AWS Security Token Service (AWS STS) allows for the provision of temporary security credentials upon request, which can be configured to expire anywhere from a few minutes to several hours. If still authorized, users can request new temporary credentials prior to expiration, representing a robust method for controlling access to resources, especially in scenarios where external services may be involved.

4.1.4. Controlling Access to Your Resources via Policies

Every request made to AWS must undergo an enforcement check to ascertain the authentication and authorization status of the requesting principal. This situation relies on the policies assigned to the IAM user or the role in use.

4.1.4.1. Policies for Granting Permissions to Access Your Resources

Policies in AWS are objects that delineate whether actions for services and resources are permitted or denied. Generally structured as JSON documents, these policies comprise several essential components including:

• Version: Indicates the policy language version; the latest is 2012-10-17.

• Statement: A collection of items that describe permissions.

• Effect: Defines whether actions are permitted (Allow) or prohibited (Deny). Note that a deny policy will take precedence over any allow policy.

• Action: A list of actions relevant to the service being targeted.

• Resource: Specifies the resources to which the actions apply.

• Condition: (Optional) Establishes specific circumstances under which the actions are applicable.

Example A: A policy permitting retrieval of objects from a particular S3 bucket could be structured as follows:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowGetObject",
      "Action": "s3:GetObject",
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::mydata/*"
    }
  ]
}

Example B: A policy denying all actions from specified IP ranges may look like:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyIPRange",
      "Action": "*",
      "Effect": "Deny",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": ["192.0.2.0/24", "203.0.113.0/24"]
        }
      }
    }
  ]
}

Elements of Example Policies

• Version: Version of the policy language.

• Statement: Collection defining permissions.

• Effect: Defines whether actions are granted or denied.

• Principal: Denotes the account, user, or role associated with the statement (not present in these examples).

• Action: List of API actions granted or denied.

• Resource: Specifies the target resources. This is optional in resource-based policies.

• Condition: Outlines circumstances for statement applicability (optional, but allows for detail).

Policies have size limitations, and it's a best practice to organize them based on the resources they pertain to.

Identity versus Resource-Based Policies

The principal types of policies encountered in AWS are definitely identity-based and resource-based policies.

• Identity-based Policies: Grant permissions to users, groups, or roles, including sub-types:

  • Managed Policies: Standalone and attachable to multiple identities.

  • AWS-managed Policies: Created and controlled by AWS.

  • Customer-managed Policies: Created by customers based on their requirements.

  • Inline Policies: Tightly bound to a specific identity.

• Resource-based Policies: These are attached to AWS resources (e.g., S3 bucket) rather than to identities. These policies specify which principals can access the resource and act as implicit inline policies.

AWS-Managed Policies Provided by AWS for Quickly Starting

AWS supplies a variety of managed policies with default configurations, which assist new users in assigning reasonably meticulous permissions without deep interactions with IAM.

Custom Policies for Fine-Grained Permissions for Every Use Case

Tailoring policies allows precise control over the permissions granted to each identity. Unlike AWS-managed policies, custom policies provide full latitude in permissions without concerns about updates affecting access rights. IAM roles facilitate the grouping of necessary permissions detached from specific identities, allowing more flexibility. Roles promote adherence to the principle of least privilege by only allowing necessary permissions, which ensures secure operations.

Trust Policies

Trust policies designate which principal may assume a role, pivotal for security. An example trust policy for a Lambda function is shown below:

{
  "Version": "2012-10-17",
  "Effect": "Allow",
  "Statement": {
    "Principal": {
      "Service": "lambda.amazonaws.com"
    },
    "Action": "sts:AssumeRole"
  }
}

The elements outlined include:

• Effect: Describe whether permissions are granted or denied.

• Principal: Denotes who may utilize the role.

• Action: Specifies which actions the principal is granted permission to execute.

Controlling Access to Resources via Tags

Resource access can further be managed through tagging, enhancing clarity and ease in permission assignments. Policies can utilize conditions based on tags to control access efficiently. An example condition policy might look like this:

{
  "Sid": "ResourceTag",
  "Effect": "Allow",
  "Action": ["cloudfront:*", "apigateway:*", "acm:*"],
  "Resource": ["arn:aws:acm:*:*:certificate/*"],
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/App": "my-first-app"
    }
  }
}

In this statement, permission for specific actions is granted based on a tag value (App) in the resources involved.

Permission Boundaries for Enforcing Role-Bounded Policies

Permission boundaries define a maximum scope of permissions an identity-based policy can confer, allowing more controlled management. For instance:

• Role A: Might hold a policy allowing Query and UpdateItem permissions.

• Role B: Could be permitted to CreateTable access.

When a permission boundary exists that allows only certain permissions, this further refines what roles can or cannot do, demonstrating flexibility in security management practices.

More Policy Types for Advanced Use Cases

Additional policy types include:

• AWS Organizations Service Control Policies (SCPs): Apply to AWS accounts within an organization to manage permissions centrally.

• Access Control Lists (ACLs): Service-specific policies that control access to services like S3, WAF, and VPC.

• Session Policies: Define permissions for temporary credentials, limiting permissions granted to what is defined in both identity-based and resource-based policies.

4.1.4.2. Creating and Testing Policies with Tool Support

Working with IAM policies often encapsulates learning required actions for various services, which can be intricate due to variability. AWS offers two essential tools for policy creation and validation:

• Policy Creation Support via GitHub Copilot: Users can leverage GitHub Copilot for assistance in creating IAM policies. Approaches include:

  1. Utilizing code suggestions while creating new resource definitions.

  2. Writing descriptive comments to articulate intentions behind policies.

The second method usually results in superior outcomes and flexibly iterates with ongoing comment additions.

• Creating Policies from Scratch with Natural Language and ChatGPT:
  ChatGPT allows users to describe policy needs freely, effectively crafting policies based on minimal input.

• Validating Your Policies against Best Practices with AWS IAM Access Analyzer:
  Access Analyzer examines policies against established best practices and syntax rules, providing prompts for possible errors or security tips when visualizing JSON in the AWS console.

• IAM Policy Simulator to Test Your Policies Before Applying Them:
  AWS Policy Simulator enables users to evaluate identity-based and resource-based policies prior to implementation, ensuring policies are functioning as intended.

4.1.5. AWS Organizations and Single-Sign-On for Comfortably Working with Dozens of AWS Accounts

This section encompasses concepts pivotal for managing multiple accounts effectively within an organization using AWS Organizations.

4.1.5.1. Centralized Consolidation with AWS Organizations

AWS Organizations is a framework that facilitates the management of numerous accounts under a unified structure. Key capabilities include:

• Account Administration: Creating and managing multiple accounts centrally, also transitioning existing accounts into the organization.

• Consolidated Billing: Billing is managed via the organization management account, providing centralized financial oversight across AWS accounts.

• Policy Implementation: Permissions and compliance policies can be centrally enforced across various accounts.

• Identity Federation: Enhanced centralized identity management across accounts and SSO capabilities facilitated through AWS Identity Center.

4.1.5.2. Management Accounts, Organizational Units, and Service Control Policies Are Used to Structure Your Organization and Separate Resources

Key components integral to AWS Organizations include:

• Management Account: The account responsible for creating the organization with comprehensive access to AWS resources, typically reserved for setup and management tasks.

• Organizations: A collective grouping of AWS accounts facilitating centralized control.

• Organizational Units (OUs): Logical groupings of accounts to enhance management efficiency.

• Service Control Policies (SCPs): Implemented policies that regulate access at organizational or account levels, enhancing security and compliance.
  Consolidated billing presents payment oversight consolidated to a management account, expediting financial processes and resource utility analysis for member accounts.

Federated and Delegated Access

AWS Organizations simplify permissions management across multiple accounts, allowing users to access and assume roles within the organization through a single set of credentials, enhancing operational efficiency.

4.1.6. Use Cases for AWS IAM

IAM incorporates numerous practical applications suitable for beginners, focusing on strategies that mitigate costs and enhance security through limited service access.

4.1.6.1. Use Case 1: Creating Users with Restricted Permissions That Are Managed via a Group

Establishing groups can effectively restrict user permissions to avoid cost variability linked to unintended resource creation.
For instance, a dedicated group of Serverless developers could be limited to using specific services like Lambda and DynamoDB, preventing accidental usage of costly resources (i.e., EC2 or RDS).

4.1.6.2. Use Case 2: Creating an S3 Bucket That's Only Accessible for Users with Activated MFA

To protect sensitive data, policies can be created for S3 buckets, only allowing access when Multi-Factor Authentication (MFA) is active. An example policy could entail denying all actions unless the user has enabled MFA, thereby enforcing stricter security protocols.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::my-restricted-bucket/*"],
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::my-restricted-bucket/*"]
    }
  ]
}

Here, if MFA is not enabled, access to sensitive resources is outright denied.

4.1.7. Tips & Tricks for the Real World

In IAM practices, fundamental principles assist in enforcing security:

• Grant Least Privilege: Always provide the minimal necessary actions to respective resources.

• Rotate Access Keys Regularly: Regular key updates decrease the potential for misuse.

• Utilize Groups for Permissions Management: Central management of multiple users under groups enhances efficiency.

• Enforce Multi-Factor Authentication: Elevate security by requiring additional verification methods for IAM users.

• Avoid Root Account for Daily Tasks: Keep daily access separate from the root user, reserving critical operations for that identity.

• Leverage IAM Roles: Encourages using roles with tailored permissions ensuring secure, controlled operations.

4.1.8. Final Words

Mastering AWS IAM is a significant undertaking due to its complexity; however, understanding its core principles offers substantial benefits. Investing time in IAM education is crucial for successful AWS security management.