Cloud Security with AWS IAM

Project Overview

This project demonstrates how to implement secure access control using AWS Identity and Access Management (IAM). I created customized policies, user groups, and permission boundaries to enforce least privilege access for different user roles within an AWS environment.

I did this project to learn about cloud security from the absolute foundation, because every company manages access permissions, and there are even dedicated "IAM Engineer" roles focused on these skills.

Tools and Concepts

AWS IAM - User management, policies, and access control
Amazon EC2 - Instance creation and tagging
IAM Policy Simulator - Testing access controls
JSON Policy Structure - Creating effective permission documents

1 Resource Organization with Tags

Tags are organizational tools that let me label my resources. They are helpful for grouping resources, cost allocation and applying policies for all resources with the same tag.

The tag I've used on my EC2 instances is called "Env", which stands for environment. The values I've assigned for my instances are "production" and "development".

Security Application: Tags provide a flexible way to apply policies to resources with similar characteristics, enabling precise access management without hardcoding instance IDs.

2 Creating IAM Policies

IAM Policies are like rules that determine who can do what in AWS. I set up policies to control who has access to the production/development instances.

I created a JSON policy that allows the policy holder (the "intern") to have permissions to do anything to instances tagged "development". They can also see information for any instances, but are denied access to deleting or creating tags for any instances.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Env": "development"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:Describe*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Deny",
            "Action": [
                "ec2:CreateTags",
                "ec2:DeleteTags"
            ],
            "Resource": "*"
        }
    ]
}

Key Components: The Effect tells whether you're allowing or denying something. The Action tells what specific operations you can perform. The Resource points to the specific AWS items the policy applies to.

3 Setting Up Account Alias

An account alias is simply a nickname for our AWS account. Instead of using a long account ID, we can reference account alias instead.

Creating an account alias took me 1 minute or less. Now, my new AWS console sign-in URL is https://josefelix-alias-company.signin.aws.amazon.com/console

Security Application: Account aliases improve usability while maintaining security, making it easier for users to access the correct AWS account without memorizing numeric IDs.

4 Creating IAM Users and User Groups

IAM users are people or entities that have access or can login to our AWS account. IAM user groups are like folders that collect IAM users so that we can apply permission settings at the group level.

I attached the policy I created to a user group, which means any user created inside this group will automatically get the attached permission to our custom policy.

Security Application: Using groups to manage permissions follows security best practices by enabling consistent access control and simplified user management at scale.

5 Testing IAM Policies

I tested my JSON IAM policy by attempting to stop both the development and production instances.

Stopping the production instance:
When I tried to stop the production instance, I was met with an error. This was because the production instance is tagged with the production label, which is outside the scope of our permission policies.

Stopping the development instance:
When I tried to stop the development instance, I was able to stop the instance, giving me a success indication. This was because the IAM permission policy allows the intern to stop the instance.

Security Application: This testing confirms that our security controls are working as intended, preventing unauthorized actions while allowing legitimate operations.

6 The IAM Policy Simulator

The IAM Policy Simulator is a tool that lets you test permission settings by defining a specific user/group/role and the action you want to test for. It's useful for saving time when testing permission settings. No more logging into another user or actually stopping resources.

I set up a simulation for whether our dev user group has permission to StopInstances or DeleteTags. The results were denied for both. I had to adjust the scope of the EC2 instances to ones that are tagged with "development". Once I applied that tag, permission was allowed for StopInstances but still denied for DeleteTags.

Security Application: The Policy Simulator enables security testing without risk, allowing administrators to verify access controls before implementing changes in production.

Security Applications

This project demonstrates fundamental cloud security principles that are applicable across organizations:

Least Privilege

Granting only the permissions needed for specific job functions enhances security and reduces potential for misuse or accidental damage.

Environment Separation

Keeping development and production resources separated via access controls prevents accidental changes to critical systems.

Tag-Based Controls

Using resource tagging for access control creates a flexible and scalable way to manage permissions across multiple resources.

Role-Based Access

Implementing permissions based on job functions ensures users only have access to what they need to perform their duties.

Challenges and Solutions

Understanding JSON Policies

Challenge: The most challenging aspect was understanding the IAM policy since it was written in JSON and contained multiple statements.

Solution: I researched AWS documentation on IAM policy structure and experimented with different configurations until I understood how the Effect, Action, Resource, and Condition elements worked together.

Testing Multi-Level Permissions

Challenge: Verifying that the combination of Allow and Deny statements worked together correctly required systematic testing.

Solution: I developed a comprehensive testing approach that checked each permission boundary, and used the Policy Simulator to validate complex permission scenarios before implementing them.

Key Takeaways

This project provided valuable insights into AWS cloud security:

IAM provides granular control over AWS resources through policies, roles, and groups
Tag-based access control enables dynamic, attribute-based permissions that scale efficiently
The principle of least privilege can be implemented effectively through well-designed IAM policies
Understanding JSON policy structure is essential for implementing sophisticated access controls
Testing and validation through the Policy Simulator helps ensure security controls work as intended

← Return to Portfolio