AWS - IAM

Managing Access with IAM

  • IAM Definition: Identity and Access Management (IAM) is a web service that manages who can access AWS resources and to what extent.

Components of IAM

  • Users: An individual person or application that interacts with AWS.

  • Groups: A collection of IAM users that share similar access needs, simplifying permission management.

  • IAM Roles: A set of permissions that can be assumed by users or other AWS services.

  • Policies: JSON documents that define permissions by either allowing or denying access to specific resources.

IAM Key Features

  • Global Scope: IAM is not specific to any AWS region, meaning policies and configurations are automatically replicated across AWS Regions.

IAM Users

  • User Characteristics: Typically, an IAM user will have a username and password for console access, as well as access keys for programmatic access.

  • Default Policy Logic: AWS follows explicit deny and allow rules. It first denies any request that is explicitly denied, allows requests that are explicitly allowed, and denies everything else by default.

Policy Types

  • Identity-Based Policies: Determine what a user or role can do; these policies are attached directly to users, roles, and groups.

  • Resource-Based Policies: Attached to resources, such as S3 buckets or Lambda functions, allowing access to users or roles in other AWS accounts.

  • Service Control Policies (SCPs): Do not grant permissions; they limit what accounts can do under an organization’s structure, creating a permission ceiling. Example: An SCP can block even admin accounts from deleting CloudTrail logs.

  • Access Control Lists (ACLs): Control access for principals in different accounts.

Federated Account Access

  • Definition: Set up with AWS IAM to authenticate users from identity providers. For example, an EHR software company can authenticate its users against the customers’ identity providers.

  • Attribute Usage: Federated identity attributes are critical in determining user access levels.

Service to Service Communication

  • Characteristics of how one AWS service interacts with another within the same account (e.g., Lambda function accessing S3 bucket).

  • Resource-Based Policy: Specifies access control; for instance, an S3 bucket can state, “I allow this Lambda role to read my objects.”

  • When to Use Resource-Based Policies:

    • When the resource owner should control access.

    • For cross-account access scenarios.

    • Applicable for services that support resource-based policies.

Managing Access Per Resource

  • Access management must be handled distinctly for each resource involved, particularly for cross-account and service-to-service communications.

Service Roles (IAM Roles)

  • Definition: A service role carries permissions that reside on the role itself rather than the resource (S3 bucket).

  • Advantages of Service Roles:

    • Provides centralized permission management.

    • Applicable to most AWS services, resulting in easier audit and reuse of roles.

  • Caution: Roles must be updated if permissions change over time.

Cross-Account Service to Service Communication

  • Two AWS services from different accounts communicate, necessitating configurations on both sides to ensure access.

  • Resource-Based Relationships: The trust must be mutual; for instance, an S3 bucket in Account B must trust a specific role from Account A to access its contents.

  • Access Requirements: Cross-account access requires both resource policies on the target service and identity policies on the IAM role being used.

  • Usage Considerations:

    • Use when the resource supports resource-based policies.

    • Simpler for cross-account access without complex role-switching logic.

    • Note: Bucket policies can become complicated with many accounts involved.

    • Role Assumption: A process where the instance temporarily assumes a different role in another account, defined with trust policies allowing account switching.

Approaches to Cross-Account Policies

  • Cross-Account Resource Policies: Allow external roles to access specific resources directly.

  • Cross-Account Role Assumption: Involves the role assumption mechanism, which can be better for tighter access control requirements.

Multi-Factor Authentication (MFA)

  • Policy Enforcement: IAM policies can enforce MFA for specific actions, thereby enhancing security.

  • Priority of Denials: Explicit denies always take precedence over any allowed permissions, even for users with administrator access.

MFA in Programmatic Access

  • Utilization of the AWS Security Token Service (STS) to request temporary credentials that also enforce MFA requirements for operations.

  • MFA Delete for S3: A feature requiring an MFA code for operations like deletion of objects or versions locked in S3.

IAM Identity Center

  • Functionality: Centralizes access management across AWS environments and accounts, enhancing user and group management.

  • Deployment Options:

    • Through AWS Organizations.

    • Using a single AWS account to support isolated application deployments.

  • User Management: Users can be created directly within the IAM Identity Center admin interface or imported from an existing workforce directory.

  • Identity Sources: Sources from which the Identity Center accesses users and groups, including:

    • Native Directory.

    • External identity providers like Okta or Azure AD.

    • AWS Directory Service, connecting AD to AWS.

Permission Sets

  • Definition: Reusable collections of permissions that define specific access levels within AWS environments.

  • Application: Can be designed for distinct job functions such as CloudOps Engineer or Security Analyst.

  • Assignments: Link users/groups to specific permission sets within AWS accounts, determining access levels to various resources.

    • Example: A software development company with development, testing, and production accounts wherein different groups have defined permissions across levels: DevOps-Team group receives PowerUserAccess in development and ReadOnlyAccess in production.

Application Assignments

  • Determine which users/groups can access specific applications integrated with IAM Identity Center.

    • Example for Media Company:

      • Content-Production Group: Access to AWS applications like Amazon WorkSpaces and Amazon WorkDocs.

      • Marketing-Analytics Group: Access to Amazon QuickSight and enterprise design software utilizing SAML integration.

AWS Accounts and Access Management

  • Nature of AWS Accounts: Accounts that users can access through Identity Center, creating a centralized access portal for AWS resource management.

  • Access Portal: A personalized page through which users can access assigned resources and applications.

Access Control with Attributes and Tags

  • IAM Tags: Key-value pairs attached to IAM principals and AWS resources used in policy evaluations.

    • Examples:

      • Environment = Production

      • Department = Finance

      • Project = Alpha

  • Control Usage: Tags can be leveraged to manage access to various AWS resources intelligently.

Tag-Based Access Control in AWS Services

  • Different AWS services support tag-based access control differently:

    • Services like Amazon EC2, Amazon RDS, and Amazon DynamoDB facilitate direct tag comparisons using aws:ResourceTag for authorization.

    • Amazon S3 supports alternative methods, like prefix-based permissions, due to differing policy requirements.

  • Important Note: Not all AWS services support the aws:ResourceTag condition key, necessitating consultation of AWS documentation for service-specific authorization guidelines.