How to set AWS S3 Write Permissions with Relay
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.
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.
Relay may show you an error about a missing required connection. This happens if your workflow is not yet connected to an AWS account.
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.”
In the next popup, fill in the access key ID and secret access key of the IAM user you created earlier.
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
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.
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=http://acs.amazonaws.com/groups/global/AuthenticatedUsers
The ACL will then look like this:
If you head back to the Management Console, you’ll see this:
Now, it’s time to launch our Relay workflow. Be sure to set
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.
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
false, if desired.
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,6runs 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:
Relay’s documentation includes more information about triggers and their types.
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 https://relay.sh/ to start automating your DevOps maintenance today.