Setting Up an Organization in AWS

The following guide describes how to define an organization in AWS, with granting permissions to end-users based on groups.

Demo Organization

For the purpose of this guide, we assume we are working with the following organization (illustrating a section of a company):

  1. The Organization has three teams: Sales, Marketing and Finance.
  2. In the Sales team there are two users: Sally and Salvador.
  3. In the Marketing team there are two users: Mark and Martha.
  4. In the Finance team there is one manager: Fiona.

The organization would like to have the following file structure:

  1. The Sales team can only access files in the Sales bucket.
  2. The Marketing team can only access files in the Marketing bucket.
  3. The Finance manager can access files in both the Sales bucket and the Marketing bucket, as well as the Finance bucket.
  4. All users can access files in the Shared bucket.

These S3 buckets were created:

  1. yarkons3-sales
  2. yarkons3-marketing
  3. yarkons3-finance
  4. yarkons3-shared

Naturally, your organization will not be the same; however, the way to define user permissions described below is generic and closely follows Amazon’s guidelines and best practices for setting up user permissions with S3. As long as your organization is defined in a manner similar to this, you should be able to proceed to setting up Yarkon with no trouble.

Set up AWS Users, Groups and Permissions

The “Best Practice” approach to AWS permissions is to grant access to users through groups. Group membership grants the users who are members of the group all permissions allowed to the group. The group gets its permissions through a Policy. A policy is where you define what is allowed and what is denied, by associating AWS resources to AWS actions. For more, please review the AWS IAM documentation.

To start, log in to the AWS console and go to the IAM service.

Our first step is to create the user accounts. We will use this opportunity to also create the All-Users group and its policy; in our sample, the All-Users group is used to grant access to all users to the list of buckets we use.

Note about naming conventions – in this example we use the format “Group-Name” to name our group and “account-name-group-name-policy” for the Policy associated with it, to make it easier to read through. You can choose whichever format you prefer for the names, as long as it is following the naming rules defined by AWS.

Create Users

On the left side, click Users, then click the “Add User” button. In the form, enter the first user name, and continue to click the “Add another user” link until you have them all.

For “Access Type”, you can choose either one. If you are going to give these users access to the AWS console, choose the “AWS Management Console Access”; otherwise, choose the “Programmatic access” option. This will create access keys for each user, but you don’t have to share these with the users, so no harm done.

When you are done typing in all user names, click the “Next: Permissions” button.

In this guide, we are creating an AWS user for each end user. This is by no means necessary for Yarkon – if you prefer, you can simply use an IAM Group or an IAM Role to grant permissions to your end users; this is somewhat less flexible, but requires considerably less IAM work, especially when you have a large number of users that all share the same permissions.
Another approach to accomplish the same, is to create a single generic AWS IAM user, and use it to grant permissions to all users.

Create Group for All Users

In the next step we will give the users permission to access the shared bucket. We will accomplish that by creating a group. Make sure the selector is on “Add users to group” and click the “Create group” button.

The Create group form is now displayed.

We name the group for all users with the appropriate name, “All-Users”. This is a good opportunity to create the access policy, so to do that, click the button “Create policy”

Create Policy for All Users

A “Policy” is a container for permissions. A permission can be either Allow or Deny, of a specific Action (or Actions), on a specific AWS resource (or resources). Policies can be attached to a User, Group or a Role, defining what these entities can (or cannot) do. In this case, we will follow the standard practice of assigning the policy to the group of users.

With the Create policy form open, choose the “Create Your Own Policy” option.

Name the policy following your naming convention. For this example, we use the name “yarkons3-all-users-policy”.

To grant users permission to a specific bucket, we use the following policy template. In our case we want to grant our users access to the shared bucket named yarkons3_shared, so just replace accordingly in the template (there are two places the bucket name is used, so make sure you replace both).

    "Version": "2012-10-17",
    "Statement": [
            "Effect": "Allow",
            "Action": [
            "Resource": [
            "Effect": "Allow",
            "Action": [
            "Resource": [

If you have more than one bucket, add them all following the same format, comma delimited, in between the square brackets following the “Resource” tag.

Make sure to verify that your policy is correct by clicking the button “Validate Policy”.

Permissions Explained

Below is a detailed explanation of all permissions required.

Bucket Level Permissions

At the bucket level, the following permissions must be granted:

  • s3:ListBucket – Allows the user to access the bucket and its metadata. The metadata includes information such as the bucket creation time, its owner and other properties.
  • s3:GetBucketLocation – Allows the user to find out which region a bucket belongs to. This information is used for display only, and can help the user decide which bucket to use based on the associated cost of storage in that AWS region.
  • s3:ListAllMyBuckets – Allows the user to discover the buckets she is allowed to access. Note that this permissions only allows the user to view a list of the buckets, but does not grant the user the actual ability to see the documents stored in the bucket.

Bucket Content Level Permissions

At the bucket content level, the following permissions can be granted:

  • Required:
    • s3:GetObject – Allows the user to access a document in the bucket. This is basically a read permission on a document.
  • Optional:
    • s3:GetObjectAcl – Allows the user to see the permissions on a document, such as who’s allowed to modify it, etc.
    • s3:PutObject – Allows the user to add a document to the bucket. This is basically a write permission on a document.
    • s3:PutObjectAcl – Allows the user to change the permissions on a document, such as who’d be allowed to modify it, etc.
    • s3:DeleteObject – Allows the user to delete a document.

Complex Permissions

The AWS IAM permission system is highly configurable and can be used to achieve a very fine grain structure of permissions granted to end-user. Please consult with the extensive AWS documentation on the subject to see what else can be done.

Whichever permission structure you end up using in AWS, Yarkon will respect. An end-user will never get access to a resource unless access had been granted by the system administrator.

Note about using generic permissions

When using the Integrated Security Model, you have to explicitly list the buckets you want the user/group to have access to – you can use the * character if you have many.

Do not attempt to attach a generic policy such as AmazonS3FullAccess instead of taking the time to create a user defined policy as described here. This creates a potential security risk, so as a precaution to avoid any inadvertent side effect, Yarkon ignores such policies if directly attached to a user or a group.

If you still want to override this safety measure (highly discouraged), you can use a “full access” user defined policy such as this one:

    "Version": "2012-10-17",
    "Statement": [
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::*"

Complete Creating the Group and Users

When you are done with creating the policy, the user interface will return to the Create group form. Use the filter box to limit the list to show only your policy, and select it using the checkbox to its left.

Then click the button “Create group”. If all went well, you should see the Review form, with all five users listed and the group name displayed in the list below.

Click the button “Create users” to confirm. The final confirmation screen should show the names of all five users.

Click “Close” to complete this step.

Create Other Groups

The next step is to create the groups for the teams. The steps are similar to what we did before. We will start with the Finance team.

Start with the policy. Following the same naming convention we used before, we name it yarkons3-policy-finance. We use the same policy template we used before, making sure to put in the bucket name yarkons3-finance.

Validate the policy and click the “Create policy” button.

Proceed to create the Finance group. Name it “Finance”, and attach the policy you just created to it.

The last step in creating the Finance group is adding the users. In this example, the group only has one user, Fiona, but the same process should be followed for any number of users.

Choose the Groups from the left sidebar, locate the "Finance* group in the list and click its name to get to the Summary page for the group.

Choose the Users tab, and click the “Add Users to Group” button.

From the form displayed, choose the user Fiona and add her to the Finance group.

This completes the work required for the Finance team. If in the future a new person joins the team, all you’d have to do is create a user record for this person, and add the user to the Finance group. This will take care of all permissions needed.

Repeat the same steps for the Sales and for the Marketing groups.

Finish Organization Setup

When all is done, the organization’s Groups page should looks like this:

  • The All-Users group has all five users, Fiona, Mark, Martha, Sally and Salvador.
  • The Finance group has only one user, Fiona.
  • The Marketing group has three members, Mark and Martha, and Fiona who oversees the group.
  • The Sales group has three members, Sally and Salvador, and Fiona who oversees the group.

Note: an alternative way to get to the same conceptual result would have been to put only direct members of the team in the group (so for instance, the Marketing group would only include Mark and Martha) and allow the finance user Fiona access to the Sales and Marketing buckets access by adding these buckets to the policy created for the Finance group. Either approach works and you can choose based on what you usually do or prefer.