COMP 4635 - W2 Lab 3: Using Resource-Based Policies to Secure an S3 Bucket

--- tags: comp4635(2025) --- # COMP 4635 - W2 Lab 3: Using Resource-Based Policies to Secure an S3 Bucket ## Code of Ethics :::danger * The lab exercises for the course should be attempted ONLY INSIDE THE SECLUDED LAB ENVIRONMENT documented or provided. Please note that most of the attacks described in the lab sheet would be ILLEGAL if attempted on machines that you do not have explicit permission to test and attack. The university, course lecturer, lab instructors and teaching assistants assume no responsibility for any actions performed outside the secluded lab. * The lab network should be regarded as a hostile environment. No sensitive information should be stored on your virtual machine that someone is able to gain access to it. * Do not intentionally disrupt other students who are working in the labs or hack into other student's physical or virtual machines. ::: ## Method of Submission In the following lab, each checkpoint will require you to submit some files **with designated names**. Put all files into a folder and compress them into a ZIP archive named `w2lab3-<your-id>.zip`, where `<your-id>` should be replaced with your student ID. Submit the ZIP archive [on Canvas](https://canvas.ust.hk/courses/63913/assignments/385049). There are in total **9** checkpoints, with **1** of them as bonus. The base mark is **16** points. ## Accessing the AWS Management Console 1. At the top of [the lab's Canvas page](https://awsacademy.instructure.com/courses/122155/assignments/1385744) (login if necessary), choose ▶ **Start Lab**. - The lab session starts. - A timer displays at the top of the page and shows the time remaining in the session. 💡**Tip:** To refresh the session length at any time, choose ▶ **Start Lab** again before the timer reaches 0:00. - Before you continue, wait until the circle icon to the right of the AWS● link in the upper-left corner turns green. When the lab environment is ready, the AWS Details panel will also display. :::danger Do NOT choose the AWS link to connect to the console in this lab. You will access the console in a different way than you do in most labs. ::: 2. Log in as the IAM user named _devuser_: * Choose the **AWS Details** link at the top of the page. * Copy the **IAMUserLoginURL** value, and load it in a new browser tab. * For **IAM user name**, enter `devuser` * For **Password**, enter the **IAMUserPassword** value from the AWS Details panel on the lab instructions page. * Choose **Sign in**. The AWS Management Console displays. 3. Arrange the AWS Management Console tab so that it displays alongside these instructions. Ideally, you will be able to see both browser tabs at the same time, to make it easier to follow the lab steps. ⚠ **Do not change the Region unless instructed to do so**. 4. The instructions provided in the lab's Canvas page may look similar, but submission details only exist in this one, and there may be changes that could affect your grading. Therefore, please refer to this lab sheet. 5. In this lab environment, access to AWS services and service actions might be restricted to the ones that are needed to complete the lab instructions. You might encounter errors if you attempt to access other services or perform actions beyond the ones that are described in this lab. ## Objectives In this lab, you will learn how to configure permissions by using AWS Identity and Access Management (IAM) identity-based and resource-based policies, such as Amazon Simple Storage Service (Amazon S3) bucket policies. You will also learn how IAM policies and resource policies define access permissions. After completing this lab, you should be able to do the following: * Recognize how to use IAM identity-based policies and resource-based policies to define fine-grained access control to AWS services and resources. * Describe how an IAM user can assume an IAM role to gain different access permissions to an AWS account. * Explain how S3 bucket policies and IAM identity-based policies that are assigned to IAM users and roles affect what users can see or modify across different AWS services in the AWS Management Console. ## Scenario The following diagram shows the architecture that was created for you in AWS at the _beginning_ of the lab. ![Starting architecture with an IAM user, group, and policy, and S3 buckets](https://hackmd.io/_uploads/BkeFM9v0mgg.png) The lab environment has three preconfigured Amazon S3 buckets: _`bucket1`_, _`bucket2`_, and _`bucket3`_. The environment also has a preconfigured IAM role, which allows access to certain buckets and their objects when the role is assumed. You will analyze different policies to better understand how they control your access level. By the _end_ of this lab, you will have created the architecture shown in the following diagram. ![Architecture now includes a state machine, three Lambda functions, SNS topic, and email report](https://hackmd.io/_uploads/BJm7qwAmex.png) :::success ### Checkpoint 1 (2 marks) Submit a screenshot, named **`cp1.{png/jpg/jpeg}`**, showing the AWS console. We want to make sure you've followed the instructions above correctly, as it differs from other labs. Make sure your screenshot shows the following: - The AWS console home - You are logged in as _`devuser`_ (Your username should be on the top right corner) ::: ## Task 1: Attempting read-level access to AWS services Now that you are logged in to the console as the IAM user named _devuser_, you will explore the level of access that you have to a few AWS services, including Amazon Elastic Compute Cloud (Amazon EC2), Amazon S3, and IAM. 1. Open the Amazon EC2 console: * From the ᎒᎒᎒ **Services** menu, choose **Compute** > **EC2**. * In the left navigation pane, choose **EC2 Dashboard**. Many ⊗API Error messages display. This is expected. 2. Attempt some actions in the Amazon EC2 console: * In the left navigation pane, choose **Instances**. In the Instances list, a message displays _"You are not authorized to perform this operation"_. * Choose Launch instances * Scroll down and choose the Key pair name drop down list. A message displays _"You are not authorized to perform this operation"_. Notice that Key pair name is a _required_ setting that must be configured if you want to launch an instance. This is just one of many indications that you will not be able to launch an EC2 instance with the permissions that have been granted to you as the devuser. * In the Summary panel on the right, choose **Cancel**. 3. To explore what you can access in the Amazon S3 console, from the ᎒᎒᎒ **Services** menu, choose **Storage** > **S3**. Three buckets are listed. The bucket names are unique, but one bucket name contains _`bucket1`_, another contains _`bucket2`_, and the third contains _`bucket3`_. From the menu on the left, choose **Access Points for general purpose buckets**. You should see a message that displays **Insufficient permissions to list access points**. This is expected.  :::success ### Checkpoint 2 (2 marks) Submit a screenshot, named **`cp2.{png/jpg/jpeg}`**, showing the denial of listing access points. Make sure your screenshot shows the following: - The Access Points menu under Amazon S3 - The error message displayed ::: ## Task 2: Analyzing the identity-based policy applied to the IAM user You have observed how the _`devuser`_ IAM user is unable to access certain information and actions in both the Amazon S3 console and Amazon EC2 console. In this task, you will look at the IAM policy details that apply to _`devuser`_ to understand why you can't perform these actions. 4. Access the IAM console, and observe user and group membership settings: * From the ᎒᎒᎒ **Services** menu, choose **Security, Identity, & Compliance** > **IAM**. On the IAM dashboard page, notice that you do not have permissions to view certain parts of the page. Both messages state _"User: arn:aws:iam:::user/devuser is not authorized to perform: iam:GetAccountSummary on resource: \*"_. This is expected. * In the left navigation pane, choose **User groups**. * Choose the **DeveloperGroup** group name. On the **Users** tab, notice that _devuser_ is a member of this IAM group. * Choose the **Permissions** tab. Notice that an IAM policy named `DeveloperGroupPolicy` is attached to this IAM group. ✎ **Note:** When a policy is attached to a group, the policy applies to any IAM users who are members of the group. Therefore, this policy currently governs your access to the console, because you are logged in as _`devuser`_, who is a member of this IAM group. 5. Review the IAM policy details: * On the lower portion of the page, choose the ⊞ plus icon to the left of **`DeveloperGroupPolicy`** to display the policy details. * Review the JSON policy details, and recall the level of access that you had for Amazon EC2 and Amazon S3 in the previous task. * Notice that the policy does not allow any Amazon EC2 actions. * Notice the IAM actions that the policy allows. When you accessed the IAM dashboard, you saw a message that stated that you did not have _`iam:GetAccountSummary`_ authorization. That action is not permitted in this policy document. However, many read-level IAM permissions are granted. For example, you are able to review the details for this policy. * Notice the Amazon S3 actions that the policy allows. No object-related actions are granted, but some actions related to buckets are allowed. 6. Save the policy to a file on your computer: * To copy the JSON-formatted policy to your clipboard, choose **Copy**. * Open a text editor on your local computer, and paste the policy that you just copied. * Save the policy document as `DeveloperGroupPolicy.json` to a location on your computer that you will remember. :::success ### Checkpoint 3 (2 marks) Submit `DeveloperGroupPolicy.json`. ::: ## Task 3: Attempting write-level access to AWS services Any action that you attempt when you interact with an AWS service is an API call, whether you are using the console, AWS Command Line Interface (AWS CLI), or AWS software development kits (SDKs). All attempted API calls are recorded in the AWS CloudTrail event logs. In this task, you will attempt to make two API calls that require _write-level_ access within Amazon S3. The first action is to create an S3 bucket, and the second action is to upload an object to that bucket. After you attempt the two tasks, you will again analyze the policy attached to the IAM group to analyze why you could or could not perform the specific API calls. 7. Attempt to create an S3 bucket: * Navigate to the Amazon S3 console. 💡**Tip:** Use the ᎒᎒᎒ **Services** menu, or search for `S3` in the search box to the right of the menu. * Choose Create bucket * For **Bucket name**, enter your initials followed by the number 4635; for example, _`zba4635`_. ✎ **Note:** By default, new buckets, access points, and objects don't allow public access. Diving deeper into this goes beyond the scope of this lab, but it's important to note. * For **AWS Region**, choose **"US East (N. Virginia) us-east-1"**. * Review the settings, and then choose Create bucket at the bottom of the page. You successfully created an S3 bucket. 8. Access the bucket, and attempt to upload an object: * Choose the name of the bucket that you just created. * Choose **Upload**, and then choose **Add files**. * Browse to and choose the **`DeveloperGroupPolicy.json`** file that you saved earlier. * Choose **Upload**. A message displays _Upload failed_. * On the **Files and folders** tab on the lower part of the page, in the **Error** column, choose the **Access Denied** link. The message states _You don't have permissions to upload files and folders_. :::success ### Checkpoint 4 (2 marks) Submit a screenshot, named **`cp4.{png/jpg/jpeg}`**, showing the denial of file uploading. Make sure your screenshot shows the following: - The status screen after the upload attempt - The error message displayed after choose the **Access Denied** link ::: * Choose **Close**. * From the breadcrumbs in the upper-left corner of the page, choose **Amazon S3**. 9. Review the policy details for Amazon S3 access: * Return to the text editor where you copied the `DeveloperGroupPolicy.json` document. * Review the policy details to understand why you were able to create an S3 bucket but couldn't upload objects to it. 💡 **Tip:** The _Service Authorization Reference_ document provides a list of actions that each AWS service supports. For information about Amazon S3 actions, open the [IAM documentation](https://docs.aws.amazon.com/iam/) page, and then open the _Service Authorization Reference_ document. In the left navigation pane, expand **Actions, resources, and condition keys**, and then choose **Amazon S3**. In the **Actions defined by Amazon S3** section, the table lists every possible Amazon S3 action that can be granted or denied, along with a description of the action. :::success ### Checkpoint 5 (2 marks) Submit a text file, named **`cp5.{txt/md}`**, answering the following question: - Why were you able to create an S3 bucket but not upload objects to it? ::: ## Task 4: Assuming an IAM role and reviewing a resource-based policy In this task, you will try to access _`bucket1`_ and _`bucket2`_ while logged in as the _devuser_ IAM user. You will also try to access the buckets by using a role that was preconfigured as part of the lab setup. 10. Try to download an object from the buckets that were created during lab setup: * In the Amazon S3 console, choose the bucket name that contains **`bucket1`**. * Select **`Image2.jpg`**, and then choose **Download**. An "AccessDenied" error page appears. * To return to the Amazon S3 console, choose your browser's back button. * From the breadcrumbs in the upper-left corner of the page, choose **Amazon S3**. * Try to download the **`Image1.jpg`** file from _`bucket2`_. You receive the same error. * To return to the Amazon S3 console, choose your browser's back button. **Analysis:** As shown in the following diagram, with the permissions that are granted through membership in the _`DeveloperGroup`_, you were able to create a new bucket. However, you cannot access objects in _`bucket1`_ or _`bucket2`_.![devuser is a member of DeveloperGroup, which has DeveloperGroupPolicy attached. The policy allows the create bucket action but doesn't allow access to objects in bucket1 or bucket2.](https://hackmd.io/_uploads/ryx4qwA7xg.png) * From the breadcrumbs in the upper-left corner of the page, choose **Amazon S3**. 11. Assume the _`BucketsAccessRole`_ IAM role in the console: * In the upper-right corner of the page, choose **`devuser`**, and then choose **Switch role**. * If the Switch role page appears, choose **Switch Role.** * Configure the following: * **Account:** Enter the **`AccountID`** value from the AWS Details panel on the lab instructions page. * **Role:** Enter `BucketsAccessRole` * **Display Name:** Leave this field blank. * Choose Switch Role You successfully assumed the IAM role named _`BucketsAccessRole`_, which was preconfigured for this lab. 💡**Tip:** You can tell that you switched into the role by looking at the upper-right corner of the console. Notice that **`BucketsAccessRole`** is displayed where **`devuser`** was previously displayed. 12. Try to download an object from Amazon S3 again: * In the Amazon S3 console, choose the bucket name that contains **`bucket1`**. * Select **`Image2.jpg`**, and then choose **Download**. * Open the file to verify that the file downloaded. **Analysis:** The download was successful, which means that the policy or policies applied to the _`BucketsAccessRole`_ allow the _`s3:GetObject`_ action on _`bucket1`_. :::success ### Checkpoint 6 (2 marks) Submit **`Image2.jpg`**. If the downloaded file has extension *`jpeg`*, rename it so that it has the *`jpg`* extension. You will use this file later on. ::: 13. Test IAM access with the _`BucketsAccessRole`_: * Navigate to the IAM console. ✎ **Note:** By changing roles, the permissions that you have to interact with different AWS services have changed. As you navigate the IAM console, you will see new error messages that state that you are not authorized. * In the left navigation pane, choose **User groups**. **Analysis:** An error message displays. You no longer have permissions to view the IAM user groups page because _`BucketsAccessRole`_ does not have the _`iam:ListGroups`_ action applied to it. :::success ### Checkpoint 7 (2 marks) Submit a screenshot, named **`cp7.{png/jpg/jpeg}`**, showing the denial of user group access. Make sure your screenshot shows the following: - The user groups screen under IAM - The error message displayed - You are logged in as _`BucketAccessRole`_ ::: 14. Assume the _`devuser`_ role again, and test access to the user groups page: * In the upper-right corner of the page, choose **`BucketsAccessRole`**, and then choose **Switch back**. * In the left navigation pane, choose **User groups** again. **Analysis:** Now that you unassumed the _`BucketsAccessRole`_, you have the permissions that are assigned to the _`devuser`_ IAM user (through this user's membership in the _`DeveloperGroup`_). You are able to view the user groups page again. 15. Analyze the IAM policy that is associated with the _`BucketsAccessRole`_: * In the left navigation pane, choose **Roles**. * Search for `BucketsAccessRole` and choose the role name when it appears. * Choose the plus icon to the left of **⊞ ListAllBucketsPolicy**. This policy grants the same _`s3:ListAllMyBuckets`_ action to every resource. This permission allows you to see all S3 buckets when you assume _`BucketsAccessRole`_. * Choose the plus icon to the left of **⊞ GrantBucket1Access**. **Analysis:** This policy allows the _`s3:GetObject`_, _`s3:ListObjects`_, and _`s3:ListBucket`_ actions. Notice that this policy does _not_ grant _`s3:PutObject`_ access. The allowed actions are only granted for specific resources, _`bucket1`_ and all objects within _`bucket1`_ (as indicated by **`\*`**). The asterisk (`*`) is a wildcard character, which indicates that this would match any value. Because of this policy, when you assumed the _`BucketsAccessRole`_, you could see and download objects from _`bucket1`_. 16. Save a copy of the _`GrantBucket1Access`_ policy to your computer: * Place your cursor at the start of line 1 in the policy details, and select all the lines of code (down to line 17). * Copy the JSON-formatted policy to your clipboard. * Open a new text file on your computer, and paste the policy that you just copied. * Save the policy document as `GrantBucket1Access.json` to a location on your computer that you will remember. 17. Complete your analysis of the _`BucketsAccessRole`_ details: * Scroll back up the page, and choose the **Trust relationships** tab. Notice that the _`devuser`_ IAM user in this AWS account is listed as a trusted entity that can assume this role. Notice that the account number that appears in the upper-right corner of the console (after **`devuser`**) matches the account number in the **Trusted entities** list (without the dashes). ✎ **Note:** The AWS Security Token Service (AWS STS) will provide temporary credentials to any trusted entity that requests to assume the role. This trust policy trusts an IAM user in the same account. However, a trust policy could be configured to trust one or more principals, even in other AWS accounts. Examples of other principals are AWS services, IAM roles, and IAM users. 18. Assume the _`BucketsAccessRole`_, and try to upload an image to _`bucket2`_: * To assume the _`BucketsAccessRole`_ again, in the upper-right corner of the page, choose **`devuser`**. * Under **Role history**, choose **`BucketsAccessRole`**. * Navigate to the Amazon S3 console. * Choose the bucket name that contains **`bucket2`**. Notice that this bucket does not yet have an `Image2.jpg` file. * Choose **Upload**, and then choose **Add files**. * Browse to and choose the `Image2.jpg` file that you downloaded earlier from _`bucket1`_. * Choose **Upload**. The file uploads successfully. :::success ### Checkpoint 8 (2 marks) Submit a screenshot, named **`cp8.{png/jpg/jpeg}`**, showing the success of file uploading. Make sure your screenshot shows the following: - The status screen after the upload attempt ::: * Choose **Close**. **Analysis:** After assuming the _`BucketsAccessRole`_, you successfully accessed _`bucket1`_ to download an object. You then uploaded the same object to _`bucket2`_. After inspecting the policies attached to the _`BucketsAccessRole`_, you know that the Amazon S3 permissions that were granted to that role were limited to _`bucket1`_, as shown in the following diagram. ![The GrantBucket1Access policy is attached to the BucketsAccessRole. When the role is assumed, the user can access objects in bucket1 and upload objects to bucket2.](https://hackmd.io/_uploads/SkT45DR7xl.png) * So, how were you just now able to upload an object to _`bucket2`_? The reason will become clear in the next task. ## Task 5: Understanding resource-based policies In this task, you will inspect the bucket policy that is associated with _`bucket2`_. 19. Observe the details of the bucket policy that is applied to _`bucket2`_: * On the details page for _`bucket2`_, choose the **Permissions** tab. * In the **Bucket policy** section, review the policy that is applied to _`bucket2`_. The policy has two statements. The first statement ID (SID) is _`S3Write`_. The principal is the _`BucketsAccessRole`_ IAM role that you assumed. This role is allowed to call the actions _`s3:GetObject`_ and _`s3:PutObject`_ on the resource, which is _`bucket2`_. The second SID is _`ListBucket`_. The principal is _`BucketsAccessRole`_. This role is allowed to call the action _`s3:ListBucket`_ on the resource, which is _`bucket2`_. **Analysis:** You should now have a better understanding of how resource-based policies (such as S3 bucket policies) and role-based policies (policies associated with IAM roles) can interact and be used together. In this lab, the _`role-based policies`_ attached to the _`BucketsAccessRole`_ IAM role granted _`s3:GetObject`_ and _`s3:ListBucket`_ access to _`bucket1`_ and the objects in it. These role-based policies did not explicitly allow access to _`bucket2`_; however, they also did not explicitly deny access. The following diagram shows how the policies that were applied to the IAM user, IAM role, and bucket determined what actions you were able to perform. ![BucketsAccessRole has access to bucket1 because of a role-based policy and has access to bucket2 because of a resource-based policy.](https://hackmd.io/_uploads/SyVS5wA7gl.png) Then, while still assuming the _`BucketsAccessRole`_, you tried to upload an object to _`bucket2`_, and you were able to do it. That seemed strange based on the IAM policies that you reviewed. However, after you reviewed the _`resource-based policy`_ (in this case, a bucket policy) that was attached to the bucket, your access made sense. That bucket policy grants access, including the _`s3:PutObject`_ action, to _`bucket2`_ to the _`BucketsAccessRole`_ principal. ## (Challenge) Task 6: Uploading Image2.jpg Your objective for this challenge task is to figure out a way to upload the `Image2.jpg` file to _`bucket3`_. 20. Try to upload the file as _devuser_ with no role assumed: * Unassume the _`BucketsAccessRole`_. * Attempt to upload `Image2.jpg`, which you downloaded from _bucket1_ earlier in this lab, to _`bucket3`_. The upload fails. * Check whether a bucket policy is associated with _`bucket3`_. Maybe that will give you some indication about how to accomplish this task. You can't view the bucket policy. 21. Assume the _`BucketsAccessRole`_, and try the actions from the previous step: * Can you upload a file to _`bucket3`_? * Can you view the bucket policy now? Review the bucket policy details. Do you have an idea for how you can upload `Image2.jpg` to _`bucket3`_? * Did you figure out how to upload the file? If so, congratulations! :::success ### Checkpoint 9: Bonus 1 (3 marks) Submit a text file **`cp9.{txt/md}`** detailing how you managed to upload **`Image2.jpg`** onto _`bucket3`_. Then, submit a screenshot **`cp9.{png/jpg/jpeg}`**, showing the list of objects in _`bucket3`_. Make sure the screenshot shows the following: - The bucket name or ID showing it is _`bucket3`_ - The entry of the **`Image2.jpg`** you uploaded ::: ## Lab complete Congratulations! You have completed the lab. Remember to submit the necessary files [on Canvas](https://canvas.ust.hk/courses/63913/assignments/385049). 22. At the top of this page, choose ⏹ **End Lab**, and then choose Yes to confirm that you want to end the lab. A message panel indicates that the lab is terminating. 23. To close the panel, choose **Close** in the upper-right corner.