IAM Users and Policies: A Guide to Least Privilege

Previously in this course, we covered configuring the AWS CLI. Now that you can communicate with AWS from your terminal, we need to ensure that the identity you are using follows the Principle of Least Privilege—the security practice of granting only the minimum permissions necessary to perform a task.

Understanding IAM Fundamentals

Identity and Access Management (IAM) is how AWS manages authentication (who you are) and authorization (what you can do).

An IAM User represents a person or a service that interacts with AWS. When you first set up an AWS account, you use the "root user," which has unrestricted access. Using the root user for daily development is a significant security risk. Instead, we create IAM users with specific permissions.

IAM Policies are JSON documents that define these permissions. They are attached to users, groups, or roles.

• Managed Policies: Created and maintained by AWS or you; they can be attached to multiple users.
• Inline Policies: Embedded directly into a single user, group, or role. These are useful for one-off, highly specific permissions.

Hands-On: Creating an IAM User and Policy

For our running project, let's create a dedicated user for your development machine that has access to read S3 buckets but nothing else.

1. Create the User:

   • Log into the AWS Management Console and navigate to the IAM service.
   • Select Users -> Create user.
   • Name it dev-user and ensure "Provide user access to the AWS Management Console" is unchecked (since we are using the CLI).
   • Click through to create the user without attaching any permissions yet.

2. Attach an Inline Policy:

   • Click on your new dev-user in the IAM console.
   • Select Add permissions -> Create inline policy.
   • Switch to the JSON tab and paste the following:

JSON
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets",
                "s3:GetBucketLocation"
            ],
            "Resource": "arn:aws:s3:::*"
        }
    ]
}

• Click Review policy, name it S3ReadOnlyPolicy, and save. This user can now list buckets but cannot delete or upload files.

Testing with the Policy Simulator

Before you run commands, it is best practice to test your logic using the IAM Policy Simulator.

1. Open the Policy Simulator.
2. Select your dev-user from the list.
3. Under Service, select S3.
4. Select ListAllMyBuckets.
5. Click Run Simulation. You should see an "Allowed" result.
6. Now, try selecting DeleteBucket. Click Run Simulation again. It will return "Implicitly Denied," confirming your policy is secure.

Common Pitfalls

• Over-permissioning: It is tempting to attach the AdministratorAccess managed policy to every user. Avoid this. Even for development, start with restricted access to avoid accidental infrastructure deletion.
• Hardcoding Credentials: Never save your access_key and secret_key in your source code. Use the ~/.aws/credentials file as covered in our previous lesson.
• Confusing Users and Roles: Users are for people or long-term identity; Roles are for temporary permissions (e.g., granting a Lambda function access to a database). We will cover roles in a later lesson.

Practice Exercise

Create a second policy for your dev-user that denies them access to iam:* actions. Apply this policy and use the simulator to verify that even if you were to add AdministratorAccess later, this "explicit deny" would take precedence.

FAQ

Q: What happens if I have both an Allow and a Deny policy? A: In AWS, an explicit "Deny" always overrides an "Allow."

Q: Can I share an IAM user between two developers? A: No. Each person should have their own IAM user with individual credentials. This ensures accountability through CloudTrail logs.

Recap

We have moved beyond the root user by creating a dedicated IAM user and applying an inline policy. By using the Policy Simulator, we verified that our dev-user adheres to the principle of least privilege, ensuring our project remains secure as we scale.

Up next: Introduction to Infrastructure as Code — we will learn how to define these users and policies in code rather than clicking through the console.