Demo Configuring Users and Group Access and Policies

Welcome to this instructional session where Michael Forrester demonstrates how to configure AWS IAM users, groups, and their associated policies using the AWS Identity and Access Management (IAM) service. In this lesson, you'll learn to leverage groups for policy management—a best practice in enterprise environments—to avoid assigning policies directly to users or roles.

For example, imagine you want to create a group named "Project_A_S3_Readonly". The name clearly indicates that the group is linked to Project A and is intended for users who need read-only access to the S3 service. Enterprises often organize groups based on project name, service type, and role (e.g., operations, developer) to easily locate and manage permissions.

Consider a scenario where your environment includes multiple users (such as yourself and a colleague named Fani) and several S3 buckets for Project A. You might need one group for read-only access and another for read-write access. By attaching a read-only access policy to the appropriate group, you maintain clear and secure permission boundaries.

AWS provides a range of managed policies, but many enterprises favor customer-managed policies to have complete control over fine-grained permissions. In this demonstration, Michael creates a custom JSON-based policy for S3 read-only access. Although this example is generic, remember that in production environments, you should limit access by specifying resource names (such as the bucket name) in your policy conditions.

Below is a basic S3 read-only policy that grants permissions to list, describe, and get objects for both S3 and S3 Object Lambda:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*",
        "s3:Describe*",
        "s3-object-lambda:Get*",
        "s3-object-lambda:List*"
      ],
      "Resource": "*"
    }
  ]
}

To implement stricter security, Michael refines the policy by restricting access to a specific bucket and its objects. First, he specifies the Amazon Resource Name (ARN) for both the bucket and its content:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*",
        "s3:Describe*",
        "s3-object-lambda:Get*",
        "s3-object-lambda:List*"
      ],
      "Resource": [
        "arn:aws:s3:::mrfkksservices",
        "arn:aws:s3:::mrfkksservices/*"
      ]
    }
  ]
}

Next, he further enhances security by adding a condition that limits access to a specific source IP address—71.131.99.101/32. This ensures that S3 requests are only honored if they originate from an approved location:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*",
        "s3:Describe*",
        "s3-object-lambda:Get*",
        "s3-object-lambda:List*"
      ],
      "Resource": [
        "arn:aws:s3:::mrfkservices",
        "arn:aws:s3:::mrfkservices/*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "71.131.99.101/32"
        }
      }
    }
  ]
}

This final policy is applied to the “Project_A_S3_Readonly” group. It not only grants S3 read-only access but also restricts access to a predetermined bucket ("mrfkservices") and enforces network restrictions with a designated IP address. Remember, if any deny statements were specified, they would override these allow statements.

Once the policy is configured, attach it to the relevant user group via the IAM console. You will notice that the policy type changes from an AWS-managed policy to a customer-managed policy, indicating that you now have full control and can modify the policy as needed. Enterprises typically prefer customer-managed policies to prevent unexpected changes from AWS that might affect their security setup.

Summary

This lesson demonstrated how to create a user group named "Project_A_S3_Readonly" that includes two users, attach a customer-managed policy granting S3 read-only access, and enforce network restrictions based on a specific source IP address. By following these steps, you can achieve granular permissions tailored to meet your security compliance needs.

See you in the next lesson!