How to set AWS S3 Write Permissions with Relay

Blog post cover

How to set AWS S3 Write Permissions with Relay

Misconfigured resources are a big contributor to compromised cloud security. If you have misconfigured Amazon S3 buckets, for example, malicious actors could access your data, then inappropriately or illegally distribute this private information, putting your company’s security at risk.

Policies and regular best practices enforcement are key to reducing this security risk. However, checking and enforcing security is time-consuming, so automating regular security checks is required to keep ahead of potential security breaches. Relay uses simple workflows to automate security tasks so you can keep your cloud environments secure with minimal manual work.

This article will demonstrate how to use a Relay workflow to ensure that only authenticated users can write to Amazon Web Services (AWS) S3 buckets with WRITE permissions.

Setting Up Relay for AWS

The previous article walked you through creating a Relay account and setting up Visual Studio Code for editing workflows. The workflow in this article uses an AWS connection, so you need to create an IAM user with permissions to edit S3 buckets, as per the previous article.

Creating a Workflow

Relay has a number of sample workflows with code to get you started, including a workflow to change buckets that have write access for All Users to private. We will explore that workflow below.

Restrict S3 buckets with WRITE permissions to all authenticated users

After navigating to the appropriate workflow, press the “Use this workflow” button. A popup to create the workflow will appear. Enter a name, and optionally a description, then press the “Create workflow” button.

Use the s3-restrict-authenticated_user-write-buckets workflow

Relay may show you an error about a missing required connection. This happens if your workflow is not yet connected to an AWS account.

Your workflow has one missing connection

Click on “Fill in missing connections,” then the “Connections” panel in the sidebar will allow you to add that connection. To do this, press the blue-encircled plus sign next to “my-aws-account.”

My workflow connections

In the next popup, fill in the access key ID and secret access key of the IAM user you created earlier.

Setup your AWS connection

After you press “Save,” you’re ready to use the workflow.

Running a Dry Run

Let’s give our new workflow a try by pressing “Run.” A popup will ask you to fill in the dryRun parameter. true means the workflow will do a dry run: it will report what changes it would make to your S3 buckets, but it doesn’t actually make them. Set this parameter to false if you do want to modify buckets.

To see exactly what the workflow does, let’s do a dry run first. After starting the run, the workflow graph will show you which step is running and which steps are completed. Clicking on each step will show you more details and let you view the logs for that step.

The three first steps help you decide which S3 bucket permissions to modify:

  • list-buckets fetches a list of all your S3 buckets.
  • get-bucket-acls retrieves the Access Control Lists (ACLs) from those buckets.
  • filter-buckets checks which of those buckets have public READ permissions and are thus deemed unsafe.

If dry run is disabled, the fourth step, approval, requires you to approve modifying the ACLs found by filter-buckets. If approved, the fifth step, modify-acls, carries out the bucket modification.

Take a look at the logs for each step to get a feel for what they do. Then, we’ll move on to a “wet run” to see the workflow’s modification step in action.

Trying a “Wet Run”

Now that we have explored a dry run of the workflow, let’s try out the workflow with dryRun set to false. To see any effect, you’ll first have to intentionally create an unsafe S3 bucket so the workflow can detect it as such and enforce the restrictions.

To get started, go to the S3 Management Console and press “Create bucket.” Fill in a name and region, and then uncheck “Block all public access.” Tick the checkbox next to the warning that appears.

Bucket settings for block public access

Scroll down to the bottom of the page and press “Create bucket.” When you’re redirected back to the Management Console, click on the name of the newly created bucket and head to the “Permissions” tab.

Then, we have to grant write access to the world. Because AWS knows this is a bad idea, they don’t allow you to do this using the Access Control List editor in the S3 Management Console. You’ll have to do it using the AWS command-line interface (CLI) instead:

aws s3api put-bucket-acl --bucket <bucket name> --grant-write uri=

The ACL will then look like this:

Access control list

If you head back to the Management Console, you’ll see this:

relay-unsafe-test-bucket in S3 management console

Now, it’s time to launch our Relay workflow. Be sure to set dryRun to false when starting the run.

The filter-buckets step will now detect this new bucket:

Found 1 bucket(s) that have public WRITE permissions: relay-unsafe-test-bucket

Once you get to the approval step, press “Yes.” After modify-acls is done, head back to the S3 Management Console and the Permissions tab of the bucket. You’ll see that the workflow has successfully removed the unsafe permissions.

Access control list updated

Setting up a Trigger

To keep your S3 buckets safe, it’s convenient to regularly run the workflow automatically, rather than running it manually. You can do this using triggers. Relay offers three types of triggers:

  • Schedule triggers: time-based scheduling, similar to cron jobs on Linux.
  • Push triggers: allows external services to trigger the workflow by making an HTTP POST request with a JSON web token (JWT) access token.
  • Webhook triggers: allows external services to trigger the workflow by POSTing a payload to a workflow-specific URL.

For this workflow, we’re going to use a schedule trigger. If you look at the “Code” tab of the workflow, you’ll see that there is already a schedule trigger prepared in a comment. Uncomment those lines and change dryRun to false, if desired.

The schedule property indicates when to run the workflow. The format is equivalent to the Linux crontab format. There are five values: minute, hour, day of the month, month (one-based, so 1 is January), and day of the week (where 0 is Sunday), in that order. An asterisk means “any value.” The default schedule for this workflow is 0 * * * *, meaning that it will run at the start of every hour because minute is zero and all other values are “any.”

The crontab format is more flexible than just numbers and asterisks. You can also specify multiple values using a comma, a range using a hyphen, and steps (“every fourth hour”-style) using a slash. Examples include:

  • 0 3 * * 0,6 runs at 3 AM on Sunday and Saturday
  • 0 0-3 * * * runs every day at midnight, 1:00 AM, 2:00 AM, and 3:00 AM (ranges are inclusive)
  • 4-54/10 * * * * runs every hour at :04, :14, :24, :34, :44 and :54

After you enable the schedule trigger, it will appear as the first block in the workflow graph:

Automated trigger in Relay workflow

Relay’s documentation includes more information about triggers and their types.

Next Steps

We configured a Relay workflow to restrict access to the relevant S3 buckets, then set a schedule to automatically check and enforce those restrictions. This will help us save time while keeping our write permissions secure on cloud services.

Relay enables you to conveniently automate your DevOps maintenance. Check out Relay’s other flows to help you maintain and enforce other AWS resource policies. You can also expand these examples to develop workflows for any Azure, AWS, or Google Cloud Platform (GCP) resources. To learn more about Relay’s workflows, refer to their official documentation.

Automating your cloud write permissions helps keep your organization’s information secure while saving time, boosting your DevOps team’s productivity, and helping them focus on building great new features. Check out to start automating your DevOps maintenance today.