How to use Wasabi Policy Generator

Wasabi Policy Generator is a tool which allows users to create policies in a visual editor format and automatically creates JSON policies that drives access to Wasabi's resources.

This tool is similar in use to AWS Policy Generator and hence it is strongly recommended that one must read about policies and permissions here before creating complex policies.

Few things to note before using Wasabi Policy Generator:

• Currently you can create policies for four types of services:

1. iam

2. s3

3. sts

4. aws-portal

•  You can add multiple rules in one policy.

•  You can add multiple conditions in one statement.

•  Currently you can only add one statement using this tool, the ability to add multiple statements is planned for future release. In cases wherein you need to have multiple statements, you can edit the policy in the editor box after creating a policy using policy generator. 

In order to use this Policy Generator, log in to the Wasabi console, select Policies from the menu and click on "create policy". 

Start creating policies by clicking on "Policy Generator" as shown in the screenshot:

------------------------------------------------------------------------------------------------------

1. Policy to allow all IAM actions for a sub-user

Start with a policy name and description, click on Rule, select Allow.

Here we are selecting "iam" service as shown in the screenshot:

In this case, we are making a policy to allow ALL iam actions for all iam polices, we are selecting "All Actions" and '*' for Resource Name as shown in the screenshot:

Hit Apply and JSON policy document will be automatically created for you. Now you can click "create policy" and attach this policy to any sub-user whom you want to allow all iam actions:

2. Policy to allow creating, updating, deleting, listing, getting, and setting the default version for all policies for a sub-user

Start with adding name and description to the policy, click rule --> select allow --> select iam service

This time, instead of allowing ALL iam actions, we will individually select only the required actions that we need to create this policy. As shown in the screenshot, click on the dropdown menu and start selecting action one by one.

Once you select one action, click on the "Add Rule" button at the bottom to add more actions and repeat the same process until you have added all the below actions:

 "iam:CreatePolicy", "iam:CreatePolicyVersion", "iam:DeletePolicy", "iam:DeletePolicyVersion", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:ListPolicies", "iam:ListPolicyVersions", "iam:SetDefaultPolicyVersion"

Once you complete adding all actions via Add Rule, your generated policy will look like this:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "iam:CreatePolicy",
 "Resource": [
 "*"
 ],
 "Condition": {}
 },
 {
 "Effect": "Allow",
 "Action": "iam:CreatePolicyVersion",
 "Resource": [
 "*"
 ],
 "Condition": {}
 },
 {
 "Effect": "Allow",
 "Action": "iam:DeletePolicy",
 "Resource": [
 "*"
 ],
 "Condition": {}
 },
 {
 "Effect": "Allow",
 "Action": "iam:GetPolicy",
 "Resource": [
 "*"
 ],
 "Condition": {}
 },
 {
 "Effect": "Allow",
 "Action": "iam:GetPolicyVersion",
 "Resource": [
 "*"
 ],
 "Condition": {}
 },
 {
 "Effect": "Allow",
 "Action": "iam:ListPolicies",
 "Resource": [
 "*"
 ],
 "Condition": {}
 },
 {
 "Effect": "Allow",
 "Action": "iam:ListPolicyVersions",
 "Resource": [
 "*"
 ],
 "Condition": {}
 },
 {
 "Effect": "Allow",
 "Action": "iam:SetDefaultPolicyVersion",
 "Resource": [
 "*"
 ],
 "Condition": {}
 }
 ]
}

Now click on "create policy" and attach this policy to the sub-user of your choosing.

3. Policy to allow ALL s3 actions for a sub-user inside their own bucket (requires multiple statements as shown)

This time we are selecting "s3" services, allowing All actions

In the Resource Name section, add the sub-user's s3 bucket ARN which you would like to give access to and then add another rule to allow everything inside that bucket by editing the ARN as the following:

arn:aws:s3:::bucket-name/*

This is one example wherein you would require multiple statements, hence once you have the auto generated policy through the wasabi policy generator ready, go ahead and edit using the editor to add another statement as shown below before saving the policy. 

Note: To perform any bucket/object operations through the console the sub-user MUST have "ListAllMyBuckets" permission hence we have added another statement as shown below:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:ListAllMyBuckets",
 "Resource": "arn:aws:s3:::*"
 },
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": "arn:aws:s3:::bucket-name"
 },
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": "arn:aws:s3:::bucket-name/*"
 }
 ]
}

4. Creating a s3 bucket policy to allow read access to public (resource-based policy)

NOTE: These are special case policies called as resource-based policies because this policy is directly applied to the resource as opposed to an IAM user. Hence for this reason, one must include the "Principal" in your statement.

If you create a resource-based policy, you must indicate the account, user, role, or federated user to which you would like to allow or deny access. If you are creating an IAM permissions policy to attach to a user or role, you cannot include this element. The principal is implied as that user or role.

Before creating this policy, add the Principal element in the policy editor as shown below and then copy this policy to your desired bucket which you want to make public as discussed here.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": { 
 "AWS": "*" 
 }, 
 "Action": "s3:GetObject",
 "Resource": [
 "arn:aws:s3:::public-bucket-name"
 ],
 "Condition": {}
 }
 ]
}

5. Policy to restrict the client IP from which API calls are made

This example is to create a policy with a condition that says deny all API calls to your Wasabi Account if its not coming from the mentioned source IP in the condition statement. 

For example reference we have used 203.0.113.0/24 IP. You can add any value based on your IP address.

The policy will look something like this:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Deny",
 "Action": "*",
 "Resource": "*",
 "Condition": {
 "NotIpAddress": {
 "aws:SourceIp": "203.0.113.0/24"
 }
 }
 }
 ]
}

6.  Policy to grant sub-user permission to assume a role via STS

You can attach this policy to a sub-user to grant permission to call AssumeRole via sts for a role that you have already created in your account.

Make sure to use the correct ARN in Resource Name with proper Wasabi Account number and your role-name.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "sts:AssumeRole",
 "Resource": [
 "arn:aws:iam::1234567890:role/already-present-role-name"
 ],
 "Condition": {}
 }
 ]
}

7.  Policy to force MFA to allow deletion of any kind

This policy basically allows s3 actions on all resources but denies any kind of DELETES to be done in your account unless they are authorized through an MFA for authentication.

Note: To perform any bucket/object operations through the console the sub-user MUST have "ListAllMyBuckets" permission hence we have added another statement as shown earlier.

Start by allowing full s3 permission or drill down access to per bucket as shown earlier (based on your requirements).

Then keep adding Rules to Deny s3 actions such as:

s3:DeleteBucket,

s3:DeleteBucketPolicy,

s3:DeleteObject,

s3:DeleteObjectVersion

Make sure to add conditions to all those Rules which states that if MultiFactorAuthPresent is NOT present (i.e., boolean value is False) then Deny the underlying s3 action.

Finally before creating this policy, add another statement to allow ListAllMyBuckets (for console operation on buckets) using policy editor as we had done in earlier example. Here's how the policy would look like:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:ListAllMyBuckets",
 "Resource": "arn:aws:s3:::*"
 },
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": "*"
 },
 {
 "Effect": "Deny",
 "Action": "s3:DeleteBucket",
 "Resource": "*",
 "Condition": {
 "Bool": {
 "aws:MultiFactorAuthPresent": "false"
 }
 }
 },
 {
 "Effect": "Deny",
 "Action": "s3:DeleteBucketPolicy",
 "Resource": "*",
 "Condition": {
 "Bool": {
 "aws:MultiFactorAuthPresent": "false"
 }
 }
 },
 {
 "Effect": "Deny",
 "Action": "s3:DeleteObject",
 "Resource": "*",
 "Condition": {
 "Bool": {
 "aws:MultiFactorAuthPresent": "false"
 }
 }
 },
 {
 "Effect": "Deny",
 "Action": "s3:DeleteObjectVersion",
 "Resource": "*",
 "Condition": {
 "Bool": {
 "aws:MultiFactorAuthPresent": "false"
 }
 }
 }
 ]
}

8. Policy to allow viewing of Billing Page but deny all s3 actions 

Then add a rule to DENY all s3 actions from s3 service as shown below:

Few things to note here:

• We did NOT include another statement to allow "ListAllMyBuckets" permission even though this is a console operation simply because this is outside the realm of bucket/object operation and only concerns billing.

• This policy uses two different services - 

1. aws-portal

2. s3

• In order to execute this permission, root user must toggle "Allow IAM users and roles to Access Billing Portal" on the setting page as shown here.

• When sub-user log into the console, they will see a "Access Denied" screen flash initially (bucket listing process) and then automatically directed to billing page.

Here's how the policy would look like:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "aws-portal:ViewBilling",
 "Resource": [
 "*"
 ],
 "Condition": {}
 },
 {
 "Effect": "Deny",
 "Action": "s3:*",
 "Resource": [
 "*"
 ],
 "Condition": {}
 }
 ]
}