Building effective IAM policies #AWSreInvent #SEC305

Our team actively participated in the Builders' Session focused on crafting an IAM (Identity and Access Management) policy. This report summarizes the insights and outcomes from the session

Overview

Anyone who builds on AWS should understand how to build effective IAM policies. In this session, learn the requirements for security controls and walk through the construction of IAM policies that implement those controls. See which policy types are most appropriate for each control, and walk away with some real-life examples of IAM policies that you can take back to your organization.

Session Agenda

We have four scenarios prepared, and our objective is to craft IAM policies to implement necessary controls for each scenario. Additionally, we plan to utilize Cloud9 for launching and testing the IAM policies we've developed, employing the Assessment tool to ensure their effectiveness

This tool will return results when executed after creating policies.

Set up

Prior to proceeding, ensure that the tool required to evaluate the generated policies is installed.

Next, navigate to the AWS Management Console and access 'AWS Cloud9'. Once there, open the environment specifically prepared for this session.

Download and install the tool.

$ curl 'https://static.us-east-1.prod.workshops.aws/public/a8b77c64-5ab8-49a3-8751-ba7d5351e107/assets/eval_policy-0.0.33-py3-none-any.whl' --output eval_policy-0.0.33-py3-none-any.whl
pip install eval_policy-0.0.33-py3-none-any.whl

Scenario 1. Allow access to resources for all principals within the organization

Policy

Create a policy allowing s3:GetObject for all principals to all objects in a specific bucket.

Values ​​used in policies

• AWS Organizations organization ID: o-123456

• Bucket name: MY-BUCKET

• Account: 111111111111

• Action: s3:GetObject

Created policy

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": "*",
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::MY-BUCKET/*",
        "Condition": {
            "StringEquals": {
                "aws:PrincipalOrgId": "o-123456"
            }
        }
    }]
}

After creating the policy, executing a command allows you to evaluate the created policy.

$ eval-policy --step 1 --policy policy1.json

This was done relatively quickly.

Scenario 2. Protecting platform resources with Service Control Policies

Policy

Create a Service Control Policy to deny the execution of all actions on resources with a tag where the key is team and the value is admin. Only principals with the tag key of team value of admin should be allowed to perform any actions on tagged resources.

Values ​​used in policies

• Tag on resources to protect: Key: team Value: admin

• Tag on principals that are exempt: Key: team Value: admin

• Resource: all resources

• Action: all actions

Created policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        },
        {
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/team": "admin"
                },
                "StringNotEquals": {
                    "aws:PrincipalTag/team": "admin"
                }
            }
        }
    ]
}

Scenario 3. Limit the types of EC2 instances that can be launched with identity-based policies

Policy

If the instance type is 't3.small', allow launching EC2 instances. Create an IAM policy that denies launching instances for any other instance types.

Values ​​used in policies

• Allowed instance type: t3.small

• Action: ec2:RunInstances

Created policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "ec2:*",
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Effect": "Deny",
            "Action": "ec2:RunInstances",
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "StringNotEquals": {
                    "ec2:InstanceType": "t3.small"
                }
            }
        }
    ]
}

The session included a tutorial on writing policies similar to the ones shown in the screenshot below.

Scenario 4. Prevent untrusted principals from using an AWS service as a confused deputy

Policy

Create a policy to enable an SNS topic to receive notifications from an S3 bucket.

We need to allow the AWS service principal s3.amazonaws.com to publish messages to the SNS topic. We need to prevent other AWS accounts from using the s3.amazonaws.com service as a confused deputy to publish messages to your topic.

Values ​​used in policies

• Service: s3.amazonaws.com

• Action: sns:Publish

• Region: us-east-1

• Topic name: MyTopic

• Account that the SNS topic is in: 111111111111

• Account that you want to receive notifications from: 111111111111

• S3 bucket that you want to receive notifications from: MY-BUCKET

Created policy

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {
            "Service": "s3.amazonaws.com"
        },
        "Action": "sns:Publish",
        "Resource": "arn:aws:sns:us-east-1:111111111111:MyTopic",
        "Condition": {
            "ArnEquals": {
                "aws:SourceArn": "arn:aws:s3:::MY-BUCKET"
            },
            "StringEquals": {
                "aws:SourceAccount": "111111111111"
            }
        }
    }]
}

Conclusion

The session provided not only a great opportunity to relearn IAM but also proved highly beneficial for its practical approach in introducing IAM policies through a variety of scenarios.

Resources

• Reference | Build effective IAM policies