AWS Bucket Policies – Working with AWS Storage Buckets By default, Amazon Web Services (AWS), storage buckets are relatively permissive. There are bucket-level permissions that grant permissions to grantees, but these permissions only include List, Upload/Delete and View Permissions. Edit Permissions cannot be granted. Bucket policies allow for greater control over storage buckets. Logging in to AWS console, clicking on Storage buckets and then clicking the Permissions tab will allow you to access bucket policies. You can then click on the Add Bucket Policy button. Figure 1 shows the permissions that can directly be applied to grantees. You can also see the option of adding a bucket policy. [Click on the image to see a larger view.] Figure 1: To apply a policy on the bucket, click the Add Bucket Policy button. AWS S3 displays essentially an empty dialog box when you click on the Add Bucket Policy button. Figure 2 shows that this dialog box has an area where you can edit or create a bucket policy. However, it does not have a mechanism to generate that policy. Figure 2: The policy window appears blank. Unfortunately, the AWS interface doesn’t allow you to point and click your path through the creation of bucket policies. Bucket policies are created from scratch using a JSON file. AWS offers some assistance. You can find several examples of policies in the AWS documentation. These policies are not intended to be used as-in. However, they can be used as a starting point to create your own custom policies. The anatomy of a bucket policy folder is not complicated. There are a number of strings and values in the file. The policy will determine which strings are used. The majority of policies begin with three strings.

• Version: Usually, the date on which the policy was created or changed.
• ID: A policy name.
• Statement: Defines that a set of policy settings will be followed. These policy settings are enclosed within brackets.

{This portion of the policy looks something like this: This section of the policy looks like this: “Version” – “2016-09-21”, Id : “Posey Example Policy”, Statement : [ The policies settings go here ] ]As previously noted, the policy settings that are used can vary depending on what the policy is intended to do.|As mentioned, the policy settings used can vary depending upon the purpose of the policy.} In most cases, there are five strings. These five strings are:

• Sid: The SID is the basic determinant of what the policy does. It should not be confused or confused with a Windows Security Identifier. If the action required is to add a user to an Access Control List, then the SID would likely be AddCannedAcl. The SID could also be set to IPAllow if the policy is to evaluate IP addresses. You can use a variety SIDs as described in the Examples page.
• Effect: The Effect string controls what happens to the policy when it is applied. The effect can be either to allow or deny an action in most cases.
• Principal: The Principal string determines who the policy applies. The Principal string can be set to * to apply to all accounts, but it is possible for each account to be specified.
• Action: What happens if the policy has been applied. For example, “s3:GetObject”, allows the principal to access object data.
• Resource: The bucket to which the statement is applicable. However, you cannot simply enter a bucket’s name. You must use a specific format to enter the bucket name. If, for example, the statement were to apply to a bucket named poseydemo-test, then the resource would be expressed as “arn:aws:s3:::poseydemo-test/*”.

Here is an example of a very simple bucket policy: { “Version”:”2016-09-22″, “Id”: “Posey Sample Policy”, “Statement”: