Learning AWS - IAM (Identity Access Management)

AWS
Learning AWS - IAM (Identity Access Management)

Introduction

IAM stands for Identity and Access Management. It is a global service in AWS where we create users and assign them to groups. The moment you create an AWS account, a root account is created by default. This root account should not be used or shared for daily operations. Instead, we create users within IAM using this root account. Each person gets a separate account, and users can be grouped for easier management.

Core Concepts

What is a Resource?

A resource is an entity that you create in AWS. Resources are the objects upon which actions are performed. Examples include:

  • Amazon S3: Buckets and objects
  • AWS Lambda: Functions
  • Amazon DynamoDB: Tables
  • Amazon EC2: Instances

What is a User?

A user in IAM represents a person or application that interacts with AWS resources. Users have credentials and are assigned permissions through policies. They can perform actions on resources based on the permissions granted.

What is an Account?

An AWS account is a container for your AWS resources. It is associated with a single root user, identified by an email address and password, which has full access to all resources in the account.

What is an Action?

An action is an operation that can be performed on AWS resources. Each AWS service has its own set of actions. Examples include:

  • s3:CreateBucket – Create a new S3 bucket
  • lambda:CreateFunction – Create a new Lambda function
  • dynamodb:PutItem – Add a new item to a DynamoDB table

What is an IAM Policy?

An IAM Policy is a JSON object in a nearly human-readable format that defines permissions, dictating what a user or group can do. Here’s an example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "StatementIdentifier",
      "Effect": "Allow or Deny",
      "Action": "service:action",
      "Resource": "ARN of the resource",
      "Condition": {
        "ConditionType": {
          "Key": "Value"
        }
      }
    }
  ]
}
  • Version: Policy language version (always use 2012-10-17).
  • Statement: One or more individual statements.
  • Sid: Optional identifier for the statement.
  • Effect: Allow or Deny.
  • Action: The specific action(s) permitted or denied.
  • Resource: The resource(s) the action applies to.
  • Condition: Optional conditions for when the policy is in effect.

Policy Example

Let’s look at an example policy that allows a user to create a Lambda function:

  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowLambdaCreateFunction",
      "Effect": "Allow",
      "Action": "lambda:CreateFunction",
      "Resource": "*"
    }
  ]
}
  • Effect: Allow – Grants permission.
  • Action: lambda:CreateFunction – Allows the user to create Lambda functions.
  • Resource: * – Applies to all resources.

Implicit vs. Explicit Deny

  • Implicit Deny: Any action not explicitly allowed is implicitly denied.
  • Explicit Deny: You can explicitly deny actions, which overrides any allows.

Groups

Groups are collections of users with shared permissions.

  • Benefits:
    • Simplify permission management.
    • Assign policies to groups instead of individual users.
    • Users inherit the permissions of the groups they’re in.

Note: We cannot define inline policies for groups.

Best Practices

  1. Least Privilege: Grant only the permissions required to perform a task.
  2. Use Groups: Manage permissions through groups for easier administration.
  3. Enable MFA: Protect sensitive accounts with Multi-Factor Authentication.
  4. Rotate Credentials: Regularly change passwords and access keys.
  5. Avoid Root Account Usage: Use the root account only for initial setup and critical tasks.
  6. Use Roles for Applications: Assign roles to AWS services instead of embedding access keys.
  7. Monitor and Audit: Regularly review permissions and access logs.

Why Create Groups and Users?

When we want to allow others to use our AWS account, we need to give them specific permissions. This is where IAM Policies come into play. We can assign IAM Policies to both users and groups.

Example: Groups and Users

Imagine we have three groups and six users:

  • Group A: User 1, User 2, User 3
  • Group B: User 3, User 4
  • Group C: User 4, User 5, User 6

This means:

  • User 3 is a member of both Group A and Group B.
  • User 4 is a member of both Group B and Group C.

Here's a visualization:

       +-------+                                                     +-------+
       | User 1|                                                     | User 5|
       +-------+                                                     +-------+
           ^                                                             ^
           |                                                             |
       +-------+      +-------+      +-------+      +-------+        +-------+
       |Group A|<---->| User 3|<---->|Group B|<---->| User 4| <----> |Group C| 
       +-------+      +-------+      +-------+      +-------+        +-------+
           |                                                             |
           v                                                             v
       +-------+                                                     +-------+
       | User 2|                                                     | User 6|
       +-------+                                                     +-------+

Multi-Factor Authentication (MFA)

Once users and groups are created, it's crucial to protect them from being compromised. AWS provides two defense mechanisms: password policies and Multi-Factor Authentication (MFA).

Password Policies

A strong password policy enhances account security. In AWS, you can set up a password policy with options such as:

  • Minimum password length
  • Specific character types (uppercase, lowercase, numbers, special characters)
  • Allowing or disallowing users to change their own passwords
  • Requiring periodic password changes (e.g., every 90 days)
  • Preventing password reuse

Multi-Factor Authentication (MFA)

MFA adds an extra layer of security by requiring a password and a security device. Even if a password is compromised, the account remains secure as the hacker would also need the physical device.

Types of MFA Devices in AWS

  • Virtual MFA Device: Use Google Authenticator or Authy on a phone.
  • Universal 2nd Factor (U2F) Security Key: Physical devices like YubiKey.
  • Hardware Key Fob MFA Device: Provided by third parties like Gemalto.
  • GovCloud Key Fob: Special key fob for AWS GovCloud provided by SurePassID.

IAM Roles

IAM Roles are used to assign permissions to AWS services, Common roles include EC2 Instance roles, Lambda Function Roles, and CloudFormation Roles.

Roles

An IAM role is similar to a user but is not associated with a specific person. Roles are meant to be assumable by anyone who needs them, whether that’s a user or an AWS service. mostly intended for AWS services instead of people but people may assume a role. For example, an EC2 instance may need permissions to perform actions on AWS. We create an IAM Role and assign it to the EC2 instance.

  • Use Cases:
    • Granting AWS services permissions to act on your behalf (e.g., EC2 accessing S3).
    • Cross-account access.
    • Temporary access for users or applications(Assume Role).

Differences Between Roles and Groups

  • Roles:

    • Assumable Entities: Can be assumed by any entity that needs them, including AWS services, users, or applications.
    • Temporary Credentials: Provide temporary security credentials for the duration of the role session.
    • Cross-Account Access: Facilitate access between different AWS accounts through trust relationships.
    • Not Associated with a Specific User: Unlike users, roles are not tied to a single person or identity.
    • Use Cases:
      • Delegating access to users or services in another AWS account.
      • Granting AWS services permissions to interact with other AWS services on your behalf.
      • Enabling federated users (from corporate directories) to access AWS resources.

  • Groups:

    • Collection of Users: Consist of multiple IAM users that share the same permissions.
    • Permission Management: Simplify administration by allowing you to assign policies to a group, and all users in the group inherit those permissions.
    • Cannot Be Assumed: Groups cannot be assumed by users or services; they are a way to organize and manage user permissions.
    • No Temporary Credentials: Users in a group use their own permanent credentials.
    • Use Cases:
      • Managing permissions for teams or departments within an organization.
      • Assigning standard permissions to new users by adding them to relevant groups.

While both roles and groups are used to manage permissions in AWS IAM, roles provide temporary access that can be assumed by entities needing specific permissions, often used for service access and cross-account scenarios. Groups are used to simplify the management of user permissions by grouping users with similar access needs but are not used for temporary access or cross-account access.

Example: IAM Role for EC2

An EC2 instance, which is like a virtual server, may need to perform actions on AWS. We create an IAM Role and attach it to the EC2 instance. The EC2 instance uses the IAM Role to access AWS resources based on the permissions assigned to the role.

Access Methods

There are three primary ways to interact with AWS and perform actions:

AWS Management Console

  • Web-based user interface.
  • Users sign in with a username and password.
  • Permissions are evaluated based on the user’s attached policies.

AWS CLI

  • Command-line tool for interacting with AWS services.
  • Requires configuration with access keys.
  • Example configuration:
aws configure
AWS Access Key ID [None]: YOUR_ACCESS_KEY
AWS Secret Access Key [None]: YOUR_SECRET_KEY
Default region name [None]: us-west-2
Default output format [None]: json

AWS SDKs

  • Programmatically interact with AWS services using languages like Python, Java, or TypeScript.
  • Access keys are provided in code or through environment variables.
  • Example in TypeScript:
  import AWS from 'aws-sdk';

  const lambda = new AWS.Lambda({
    accessKeyId: 'YOUR_ACCESS_KEY',
    secretAccessKey: 'YOUR_SECRET_KEY',
    region: 'us-west-2'
  });

  const params = {
    FunctionName: 'MyFunction',
    // Additional parameters...
  };

  lambda.createFunction(params, (err, data) => {
    if (err) {
      console.error(err, err.stack);
    } else {
      console.log(data);
    }
  });

Access Keys and Secret Access Keys

  • Access Keys: Public identifier for your AWS account.
  • Secret Access Keys: Secret component used to sign programmatic requests.
  • Together, they authenticate your identity when using the AWS CLI or SDKs.
  • Security Best Practice: Keep your secret access keys secure and never share them.

Trust Relationships

Trust relationships define which entities can assume a role. They are established through the role's trust policy, which specifies the trusted principal (user, group, or service) that can assume the role. Trust relationships are crucial for cross-account access and for granting AWS services permissions to act on your behalf.

  • Key Points:
    • Only roles have trust relationships, not users or groups.
    • The trust policy specifies the trusted entities (principals).
    • Trust relationships are essential for cross-account access and service roles.

Example Trust Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT-ID:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

IAM Security Tools

AWS provides security tools such as the IAM Credentials Report and IAM Access Advisor to help manage IAM effectively.

IAM Credentials Report

The IAM Credentials Report is generated at the account level and contains details of all users and the status of their various credentials.

IAM Access Advisor

IAM Access Advisor is available at the user level and shows the service permissions granted to a user and the last time those services were accessed. This helps in adhering to the principle of least privilege by identifying unused permissions.

Pro Tips

  1. Protect Your Root Account: Enable MFA and avoid using it for day-to-day tasks.
  2. Explicit Deny Overrides Allow: An explicit deny in any policy takes precedence over allows.
  3. Specify Resources: Use resource ARNs instead of wildcards to limit access scope.
  4. Use Policy Simulator: AWS provides a Policy Simulator to test and debug policies.

AWS Policy Simulator

  • Purpose: Test IAM policies to ensure they provide the intended permissions.
  • Features:
    • Simulate policy effects.
    • Identify which policies are granting or denying access.
    • Helps in debugging access issues.

Last words on IAM

Understanding AWS IAM is crucial for securely managing access to your AWS resources. By mastering users, groups, roles, policies, and trust relationships, you can ensure that your AWS environment is both secure and efficient.

Next Steps

  • Practice: Create sample users, groups, and roles in a test AWS account.
  • Explore Policies: Write custom policies and test them using the AWS Policy Simulator.
  • Learn More: Dive deeper into IAM features like identity providers and federation.

Stay tuned for more about AWS.

  • #AWS
  • #Amazon_Web_Services
  • #Solution
  • #IAM
  • #Engineering