aws prep

 

What is cloud computing?

Examples of Cloud Computing

• Infrastructure as a Service
• Amazon EC2
• GCP
• AZURE
• RACKAPACE
• Digital Ocean
• Linode
• Platform as a Service
• Elastic Beanstalk
• Heroku
• Google app engine
• Azure
• Software as a Service:#Aws Service
• Google apps (gmail)
• Dropbox
• Zoom

AWS IAM (Identity and Access Management) Explained Simply

Imagine AWS as a huge building with multiple rooms, each representing different AWS services like storage, databases, and computing power. AWS IAM is like the security system of this building that controls who can enter, which rooms they can access, and what actions they can perform.

Key Concepts in IAM (Explained Simply)

1. Users 👤

   • Think of users as individual employees in a company. Each person needs specific permissions to do their job.
   • Example: A developer may need access to servers, while an accountant only needs access to billing information.

2. Groups 👥

   • Instead of assigning permissions to each user separately, IAM allows you to create groups.
   • Example: All developers can be placed in a "Developers Group" with the same permissions.

3. Policies 📜

   • These are rules that define what a user or group can and cannot do.
   • Example: A policy might allow a user to read files from storage but not delete them.

4. Roles 🎭

   • Roles are like temporary access badges given to users or AWS services.
   • Example: A worker from another department might get a temporary access pass to enter a restricted area.

5. Multi-Factor Authentication (MFA) 🔐

   • Adds an extra layer of security by requiring a second step (like a one-time code from your phone) to log in.

Why is IAM Important?

✅ Security – Prevents unauthorized access.
✅ Control – You can grant the least required access to users.
✅ Flexibility – Users can have different permissions for different tasks.

Root User (👑 AWS Account Owner)

What is the Root User?

• The root user is the first user created when you sign up for AWS.
• It has full access to all AWS services and resources.
• The root user is tied to the AWS email address and password used during signup.

Capabilities of the Root User

✅ Full control over all AWS resources.
✅ Can create and delete IAM users and roles.
✅ Can modify billing settings and close the AWS account.
✅ Can enable special security settings like MFA (Multi-Factor Authentication) and account recovery.

Why Should You Avoid Using the Root User?

❌ Too powerful—if hacked, the entire AWS account is compromised.
❌ Cannot be restricted by IAM policies.
❌ AWS recommends using the root user only for critical tasks, then creating IAM users for daily operations.

---

2️⃣ IAM User (👤 Standard User with Controlled Access)

What is an IAM User?

• An IAM (Identity and Access Management) User is a regular AWS user created under an AWS account.
• IAM users do NOT have full access by default—they must be granted permissions.

Capabilities of an IAM User

✅ Can be assigned specific permissions (e.g., access to S3, EC2, or databases).
✅ Can belong to IAM Groups (e.g., "Developers", "Admins").
✅ Can have policies attached to limit what they can do.
✅ Can use MFA for extra security.

Example IAM User Permissions

1. Read-Only Access (Can view AWS resources but cannot modify them).
2. S3 Bucket Access (Can upload and download files from S3).
3. EC2 Management (Can start and stop EC2 instances).
4. Billing Access (Can view AWS bills but not modify settings).

Example of AWS IAM with Diagram

Scenario:

Imagine you own an online shopping website hosted on AWS. You have a team that manages different tasks, and you need to control who can access what.

Roles & Access Control:

1. Admin (You) – Full access to all AWS services.
2. Developers – Can create and update applications but cannot delete servers.
3. Support Team – Can only view customer complaints but cannot access servers or databases.
4. Billing Team – Can only view billing information.

IAM ensures that each person gets only the minimum access required for their job.

---

Diagram Representation:

Below is a simple IAM setup showing users, roles, and permissions:

                        +--------------------+
                        |     AWS IAM        |
                        +--------------------+
                                 │
  ┌──────────────────────────┬───────────────┬───────────────────┐
  │                          │               │                   │
  ▼                          ▼               ▼                   ▼
+------------+        +------------+   +------------+     +------------+
|   Admin    |        | Developer  |   |  Support   |     |  Billing   |
+------------+        +------------+   +------------+     +------------+
| Full Access |        | App Deploy |   | View Only |     | View Only  |
| (Owner)     |        | No Delete  |   | No Edit   |     | Billing Data |
+------------+        +------------+   +------------+     +------------+

---

How This Works in AWS IAM:

✅ Admin: Has a policy that allows "Full Access."
✅ Developer: Has a policy that allows "Read, Write, but No Delete."
✅ Support: Has a policy that allows "Read-Only Access."
✅ Billing: Has a policy that allows access only to billing data.

With IAM, you restrict access so that no one can accidentally or intentionally modify critical data.

AWS IAM Groups and User Membership Examples

IAM Groups help manage permissions by grouping multiple users under the same set of policies. However, AWS IAM has some specific rules:

• A user does not have to be in a group (they can have direct policies).
• A user can be in multiple groups at the same time.
• AWS does NOT support nested groups (i.e., a group cannot be part of another group).
• 
  

AWS IAM Groups and User Membership Examples

IAM Groups help manage permissions by grouping multiple users under the same set of policies. However, AWS IAM has some specific rules:

• A user does not have to be in a group (they can have direct policies).
• A user can be in multiple groups at the same time.
• AWS does NOT support nested groups (i.e., a group cannot be part of another group).

---

1️⃣ Example: User Not in Any Group

A user can exist in AWS IAM without being in a group and still have permissions via directly attached policies.

Scenario:

• User: JohnDoe
• Policy: Directly attached to allow Read-Only access to S3.

Policy Attached to User Directly:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::company-data"
        }
    ]
}

✅ JohnDoe has access to S3 but is NOT part of any group.

---

2️⃣ Example: User in One Group

A user can be part of one or multiple groups, and they inherit permissions from that group.

Scenario:

• User: Alice
• Group: Developers
• Permissions: Developers group has access to deploy applications.

Policy Attached to Developers Group:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": "*"
        }
    ]
}

✅ Alice is part of the "Developers" group, so she inherits the ability to start and stop EC2 instances.

---

3️⃣ Example: User in Multiple Groups

A user can be in multiple groups and receive combined permissions.

Scenario:

• User: Bob
• Groups: Developers, DatabaseAdmins
• Permissions:
  • Developers → Can start/stop EC2 instances
  • DatabaseAdmins → Can read/write to RDS (Relational Database Service)

Policy Attached to DatabaseAdmins Group:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "rds:DescribeDBInstances",
                "rds:ModifyDBInstance"
            ],
            "Resource": "*"
        }
    ]
}

✅ Bob gets permissions from both "Developers" and "DatabaseAdmins" groups, allowing him to manage EC2 and RDS.

---

4️⃣NESTED GROUPS

AWS IAM does NOT support nested groups. You cannot put Developers inside IT-Admins. Instead, a user must be manually added to multiple groups.

---

Summary Table:

User	Groups	Permissions
JohnDoe	❌ (No Group)	Directly assigned S3 read-only access
Alice	✅ (Developers)	Inherits EC2 start/stop permissions
Bob	✅ (Developers, DatabaseAdmins)	Can manage EC2 and RDS

1. IAM Roles (Examples)

IAM Roles are used to grant temporary permissions to AWS services or users. Here are some common role examples:

Role Name	Who Uses It?	Purpose
EC2 Access Role	AWS EC2 Instances	Allows EC2 to read/write data from S3 or other AWS services.
Lambda Execution Role	AWS Lambda Functions	Allows Lambda to interact with databases, S3, or other services.
Read-Only Auditor	Security Team	Provides read-only access to AWS services for auditing.
Cross-Account Role	External AWS Accounts	Grants access to another AWS account.
Admin Role	Admin Users	Full control over AWS resources.

---

2. IAM Policies (Examples)

IAM Policies define what actions are allowed for users, roles, or services.

Example 1: Read-Only Access to S3

This policy allows a user to view S3 buckets but not modify them.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::my-bucket"
        },
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-bucket/*"
        }
    ]
}

Example 2: Full Access to EC2

This policy grants full permissions to manage EC2 instances.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:*",
            "Resource": "*"
        }
    ]
}

Example 3: Restrict User to Only View Billing Information

This policy ensures a user can only see AWS billing details.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "aws-portal:ViewBilling",
                "aws-portal:ViewAccount"
            ],
            "Resource": "*"
        }
    ]
}

AWS IAM Policies:

IAM policies are rules that define what actions are allowed or denied for a user, group, or role in AWS. They help control who can access what in your AWS environment.

---

1️⃣ Types of IAM Policies

There are several types of IAM policies, each serving different purposes.

1. AWS Managed Policies (Predefined by AWS)

• AWS provides built-in policies for common use cases.
• Example: AdministratorAccess (full access to AWS) and ReadOnlyAccess (view-only permissions).

✅ Best for: Quick setup, using AWS-recommended permissions.

---

2. Customer Managed Policies (Created by You)

• Custom policies designed to meet specific security and access needs.
• Example: A policy that allows users to start and stop EC2 instances but not delete them.

✅ Best for: When AWS Managed Policies don’t fit your needs.

---

3. Inline Policies (Directly Attached to a User, Group, or Role)

• Inline policies are directly embedded into a user, group, or role instead of being a separate reusable policy.
• Example: An inline policy that gives an IAM user access to a specific S3 bucket only.

✅ Best for: Special one-time permissions that shouldn’t be reused.

---

2️⃣ IAM Policy Structure (JSON Format)

IAM policies are written in JSON format and consist of:

Key	Description
Version	Specifies the policy language version (always "2012-10-17")
Statement	The set of rules (allow or deny actions)
Effect	Allow or Deny (whether the action is permitted)
Action	The AWS service actions (e.g., s3:PutObject for S3)
Resource	Specifies which AWS resource the policy applies to
Condition	(Optional) Adds extra conditions, like time-based access

---

3️⃣ Example IAM Policies

Example 1: Read-Only Access to S3

This policy allows a user to list and read objects in an S3 bucket but not modify them.

json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::my-bucket",
                "arn:aws:s3:::my-bucket/*"
            ]
        }
    ]
}

---

Example 2: Full Access to EC2

This policy allows a user to perform any action on EC2 instances.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:*",
            "Resource": "*"
        }
    ]
}

---

Example 3: Allow Access to Specific S3 Bucket Only

This policy allows a user to upload and download files from a specific bucket.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject"
            ],
            "Resource": "arn:aws:s3:::company-reports/*"
        }
    ]
}

---

Example 4: Deny Deletion of S3 Objects

This policy prevents users from deleting objects in an S3 bucket.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "s3:DeleteObject",
            "Resource": "arn:aws:s3:::important-data/*"
        }
    ]
}

---

4️⃣ AWS Policy Evaluation Logic

AWS follows these rules to determine whether a request is allowed or denied:

1️⃣ Explicit Deny Wins

• If a policy explicitly denies an action, it is always denied.

2️⃣ Explicit Allow If No Deny Exists

• If there’s no deny, AWS checks if there’s an explicit allow.

3️⃣ Default Deny (Implicit Deny)

• If neither allow nor deny is found, the request is denied by default.

How MFA works in AWS:

In AWS (Amazon Web Services), Multi-Factor Authentication (MFA) is an added layer of security that requires users to provide two or more forms of authentication when accessing their AWS resources. MFA enhances the security of your AWS account by ensuring that even if an attacker gains access to your password, they cannot access your account without the second form of authentication.

1. Something you know: Your AWS credentials (username and password).
2. Something you have: A second factor, typically a time-sensitive code generated by an MFA device (hardware or virtual).

AWS supports two types of MFA:

• Virtual MFA devices: These are software-based (such as mobile apps like Google Authenticator, Authy, or AWS's own MFA app) that generate time-sensitive, rotating codes.
• Hardware MFA devices: Physical devices (like a key fob or USB stick) that generate time-sensitive codes for authentication.

Setting up MFA in AWS:

1. Go to the AWS Management Console.
2. Navigate to IAM (Identity and Access Management).
3. Choose the Users section and select the user to enable MFA for.
4. In the Security credentials tab, find Multi-factor authentication (MFA) and click Assign MFA device.
5. Follow the steps to set up a Virtual MFA device (e.g., using the Google Authenticator app) or a Hardware MFA device.

Why use MFA in AWS?

• Increased Security: Adding MFA ensures that an attacker who obtains your password will still need the physical MFA device to access your account.
• Compliance: Certain compliance frameworks (e.g., PCI DSS, HIPAA) require MFA to protect sensitive information.
• Prevent Unauthorized Access: Even if an attacker compromises your password or an API key, MFA prevents unauthorized access.

Types of MFA in AWS:

1. Root User MFA: Enabling MFA on the root user of your AWS account is highly recommended, as the root user has unrestricted access to all resources.
2. IAM User MFA: Enabling MFA for individual IAM users adds an additional security layer for accessing AWS services.
3. Federated User MFA: If you use federated authentication (via AWS SSO or third-party providers), you can configure MFA for federated users as well.

By configuring MFA, AWS users can significantly enhance their account security and reduce the risks associated with unauthorized access.

Multi-Factor Authentication (MFA) in AWS

What is MFA in AWS?

• MFA is an additional security layer that requires two or more forms of authentication.
• Enhances account security by requiring both a password and a second factor (e.g., a time-sensitive code).

IAM Policy, Role, and MFA

Scenario: Securing Access to an S3 Bucket

---

1. Root User:

• Enable MFA on the root user to add an extra layer of protection for the AWS account.

---

2. IAM User:

• Create an IAM user called JohnDoe.
• Enable MFA for the JohnDoe IAM user to ensure secure access.

---

3. IAM Group:

• Create an IAM group called S3Admins.
• Add JohnDoe to the S3Admins group to grant him group-based permissions.

---

4. IAM Policy (Access Control for S3):

• Create an IAM policy that allows access to an S3 bucket. This policy can be attached to the S3Admins group (or directly to individual users or roles).

• Here’s an example policy that allows full access to a specific S3 bucket (my-bucket):

  Example Policy for Full S3 Access (JSON format):

  json
  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": "s3:*",  // Allow all S3 actions (list, read, write, delete)
        "Resource": [
          "arn:aws:s3:::my-bucket",         // Allow access to the bucket itself
          "arn:aws:s3:::my-bucket/*"        // Allow access to all objects inside the bucket
        ]
      }
    ]
  }
  

• Explanation:

  • Action: The s3:* action grants all possible permissions (list, upload, delete, etc.) for the S3 service.
  • Resource: The arn:aws:s3:::my-bucket allows access to the bucket itself, and arn:aws:s3:::my-bucket/* allows access to all objects within that bucket.

---

5. IAM Role:

• Create an IAM role (e.g., EC2-S3-Access-Role) for an EC2 instance that needs to access the same S3 bucket.
• Attach the same S3 access policy to the role.
• Role assumption: The EC2 instance will assume this role to access the S3 bucket without needing permanent credentials.

---

6. MFA for IAM User and Root User:

• Enable MFA for both the root user and the IAM user JohnDoe to enhance security.

---

Steps to Implement:

1. Root User MFA: Enable MFA on the root user of the AWS account.
2. Create IAM User JohnDoe: Create the JohnDoe user and enable MFA for them.
3. Create Group S3Admins: Create the group and attach the above S3 access policy.
4. Add JohnDoe to S3Admins Group: Add JohnDoe to the group to grant them access.
5. Create IAM Role EC2-S3-Access-Role: Create a role for EC2 with the same S3 policy and allow EC2 instances to assume this role.
6. Attach MFA to IAM User: Enable MFA for JohnDoe to ensure secure access to AWS Management Console.