Getting Started – Yarkon Cloud for Wasabi

Before you start, we recommend you watch this short 5 minute video, taking you all the way from Sign-Up to the FREE tier of Yarkon Cloud to having an end user logging in using the Yarkon web browser application and securely accessing S3.

The following step by step guide will walk you through the full installation and setup process of Yarkon Cloud.

Yarkon Cloud is an enterprise grade system, fully integrated with AWS IAM. As such, the set up process requires working knowledge of AWS IAM.

To get your Yarkon Cloud set up, follow these steps:

  1. Subscribe to the FREE tier
  2. Set up the IAM role and policies
  3. Implement user and group level permissions
  4. Set up the provider in Yarkon
  5. Add users to Yarkon
  6. Customize the look and feel

Subscribe to Yarkon Cloud

Sign Up to the FREE Tier

To subscribe to the FREE tier, sign up from this site.

Note that your user-name should be in the format of an email – this is so that the system can send you a new temporary password in case you forget it.

When the one step sign up process is done, you should see the the overview page of the Yarkon Admin Console application.

Set up the IAM role and policies

Yarkon Cloud gets its permissions through IAM policies. It will never allow any end user more than the policy specify, and since the Yarkon cloud and client applications both only use the API to communicate with the back-end, neither can ever perform an action not explicitly allowed by the administrator. The administrator has full control over the permissions granted, and the flexibility is similar to what IAM affords.

How does it work

Yarkon Cloud has three different Security Models, controlling user access to the S3 buckets:

  • Shared security
  • Federated security
  • Integrated security

The Security Model is set using the Administration Page, Access Tab of the Yarkon Cloud application.

The following table explains the differences between them:

ModelDescriptionBenefitsChallenges
Shared
  • All end users in your account have the same access permissions.
  • Simple to implement.
  • Cannot have different permissions for different users.
Federated
  • Different users can have different permissions, using IAM users, groups and roles.
  • Very flexible, complete control over users permissions.
  • Can be used cross account.
  • Requires good knowledge of IAM.
Integrated
  • Different users can have different permissions, using IAM users, groups and roles.
  • Very flexible, complete control over users permissions.
  • Requires good knowledge of IAM.

End users, using the Yarkon Client Application, get their permissions from AWS IAM entities as following:

ModelEnd users permissionsHow to assign
SharedSame for allAutomatic, no action needed
FederatedBased on IAM user, group or roleAssociate user with permissions using Yarkon Cloud.
IntegratedBased on IAM user, group or roleAssociate user with permissions using Yarkon Cloud.

IAM Set up

As you can see in the above, there are few ways of setting up, depending on your use case and preferences. In the below, are specific guides for the different scenarios. You can definitely experiment with the settings and customize the following to best fit your own specific use case.

Create the Principal Policy

The recommended approach is to start with setting up an IAM policy. This policy can later be used with any of the security models supported by Yarkon Cloud, and should be the same for all.
Follow these steps:

  1. Sign in to the Wasabi Management Console and open the IAM tab.
  2. Create a new policy, name it something explicit, such as yarkon-console-policy.

The most generic policy – that is, one that would work for all security models – is:

{
    "Version": "2012-10-17",
    "Statement": [{
            "Sid": "AllowAllS3Actions",
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::*"
        }, {
            "Sid": "AllowUIToDisplayIAMOptions",
            "Effect": "Allow",
            "Action": [
                "iam:List*",
                "iam:Get*"
            ],
            "Resource": "arn:aws:iam::<account-number>:*"
        }, {
            "Sid": "AllowTheRoleToGetPermissions",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::<account-number>:role/yarkons3-console-role"
        }
    ]
}

In all policies shown here, make sure to replace the <account-number> with your Wasabi account number.

Details (see the Sid attributes for reference):

AllowAllS3Actions – allows the Yarkon Cloud full access to S3. If you want to limit the usage of Yarkon in your organization to a predefined set of buckets, replace the statement with the below:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowServerToIterateBuckets",
            "Effect": "Allow",
            "Action": "s3:ListAllMyBuckets",
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowServerToAccessSpecificBuckets",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "arn:aws:s3:::yarkons3-finance",
                "arn:aws:s3:::yarkons3-sales"
            ]
        },
        {
            "Sid": "AllowUserActionsLimitedToSpecificBuckets",
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::yarkons3-finance/*",
                "arn:aws:s3:::yarkons3-sales/*"
            ]
        }
    ]
}

AllowUIToDisplayIAMOptions – only required when using Federated or Integrated security models.
The Yarkon Cloud does not need IAM access when set to use the Shared security model. This setting has no impact on the permissions granted to end users. If you only intend to use the Shared model, you can remove it.

AllowTheRoleToGetPermissions – only required when using the Integrated security model. You can remove it if using any of the other models. Also, the role name specified, yarkons3-console-role assumes this is the name you’d be using for the IAM role required (see below). If you choose a different name, make sure to update here.

You can further restrict what any end user would be able to do when using the Yarkon web client application. To do so, update the statement AllowAllS3Actions (or AllowUserActionsLimitedToSpecificBuckets) to have more explicit set of permissions. For instance, if you want all users to have at most read-only access to a specific bucket, update the Action attribute in the policy to [ "s3:Get*", "s3:List*" ].

Create the Principal Role

If you plan on using the Integrated security model, you also need to create the role that would be used. If you would be using the Shared or Federated security models, you should skip this step.

This is an advanced IAM configuration. Make sure you are familiar with IAM before using these policies.

To create the IAM role:

  1. Using the Wasabi Console, go to the IAM service.
  2. Create a new role, name it something explicit, such as yarkon-console-role.
  3. For the Permissions, attach the policy you created to this role.
  4. Edit the Trust relationship for the role using the below policy (the Sid named AllowAssumeRole is what was added):
{
    "Version": "2012-10-17",
    "Statement": [{
        "Sid": "AllowAssumeRole",
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::<account-number>:root"
        },
        "Action": "sts:AssumeRole"
    }]
}

Create the Principal User

Yarkon Cloud is using API credentials (often referred to as “access keys”) to integrate with the storage provider. This final step will generate these credentials.

Important: The API access keys you are about to provision in the next step are used by the Yarkon Admin Console only. They are never shared with the end users. End users only get short lived temporary access credentials that are based on the permissions granted to these access keys.

To get these credentials:

  1. Using the Wasabi IAM Console, go to Users.
  2. Create a new user, name it something explicit, such as yarkon-console-user.
  3. Make sure to enable Programmatic access access for this user.
  1. We are not using a group in this case, so skip the Groups step.
  2. In the Policies step, enter the name of the policy you created before; in our case, it was yarkons3-console-policy.
  1. When the user is created, you will be given the API credentials associated with it. Keep these for the next step.
  2. Make sure to Download the CSV file and save it in a safe place. You will not have another option to get the API Key credentials.

Next, you want to enter the credentials into Yarkon Cloud. Use the Administration page, Access tab, and enter the credentials. Make sure to validate the credentials using the Validate button. If you are using the Integrated security model, choose it, and then select the IAM role you created from the drop down list.

You should be all set now.

Implement user and group level permissions

In the following we will go over the most common use cases for Yarkon Cloud, and provide sample policies to help you get started.

By default, Yarkon Cloud is using the Shared security model. It is simple, and works out of the box, without a need to make any additional updates to IAM on top of what was already done. Use the Administration page, Access tab to change the security model.

Shared Security Model

In this case, all users share the same permissions, as were defined in the principal policy of the cloud in the step Set up the IAM role and policies. There is no need to make any additional updates in AWS IAM.

Federated/Integrated Security Model

This is an advanced IAM configuration. Make sure you are familiar with IAM before using these policies.

In these security models, the permissions granted to a user are set by IAM policies. Later, you will associate these policies through either an IAM user, IAM group or IAM role with the users you’d be adding to Yarkon in the step Add users to Yarkon. In this step, we will be building these policies, following some common use cases.

User level permissions

To control S3 permissions at the user level, follow these steps:

  1. Using the Wasabi Console, go to the IAM service.
  2. Create a new user. Important: this user need not have any access to the Wasabi Console, so don’t check any of the boxes in Access.
  3. For the policy, use something like the below, showing how to give access to a single bucket only – just rename the <bucket-name> place-holder in the policy to your bucket name. The policy can be inline or attached.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": "arn:aws:s3:::<bucket-name>"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl",
                "s3:GetObject",
                "s3:GetObjectAcl",
                "s3:DeleteObject",
                "s3:ListMultipartUploadParts",
                "s3:AbortMultipartUpload"
            ],
            "Resource": "arn:aws:s3:::<bucket-name>/*"
        }
    ]
}

When you create the Yarkon user in the step Add users to Yarkon, in the “Add User” form, make sure to set the “IAM Type” to “User” and then select the user name you just created from the drop down.

Group level permissions

Basic

To control S3 permissions at the group level, follow these steps:

  1. Using the Wasabi Console, go to the IAM service.
  2. Create a new group.
  3. For the policy, use something like the below, showing how to give access to a single bucket only – just rename the <bucket-name> place-holder in the policy to your bucket name. The policy can be inline or attached.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": "arn:aws:s3:::<bucket-name>"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl",
                "s3:GetObject",
                "s3:GetObjectAcl",
                "s3:DeleteObject",
                "s3:ListMultipartUploadParts",
                "s3:AbortMultipartUpload"
            ],
            "Resource": "arn:aws:s3:::<bucket-name>/*"
        }
    ]
}

When you create the Yarkon user in the step Add users to Yarkon, in the “Add User” form, make sure to set the “IAM Type” to “Group” and then select the group name you just created from the drop down.

Advanced

If you already have a group based permission structure in AWS (or would like to build one), you can follow this alternative:

  1. Using the Wasabi Console, go to the IAM service.
  2. Create a new group.
  3. Add the policy as below.
  4. Create a new user and place it in the group you just created. This user will assume the permissions of the group.

When you create the Yarkon user in the step Add users to Yarkon, in the “Add User” form, make sure to set the “IAM Type” to “User” and then select the user name you just created from the drop down.

This more advanced approach allows you to “compose” user permissions using group membership, as well as override these permissions using inline and attached policies at the IAM user level.

Folder level permissions

AWS IAM allows great flexibility. The following annotated example policy shows how to create a policy that allows a user full access to a specific folder only, while disallowing any access, not even listing, of any other folder. In this example, the folder was named based on the user name, and is placed in a shared home folder.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowUserToSeeHomeBucket",
            "Action": [
                "s3:GetBucketLocation"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::<bucket-name>"
            ]
        },
        {
            "Sid": "AllowSeeingUserFolder",
            "Action": "s3:ListBucket",
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::<bucket-name>",
            "Condition": {
                "StringEquals": {
                    "s3:prefix": "home/john/",
                    "s3:delimiter": [
                        "/"
                    ]
                }
            }
        },
        {
            "Sid": "AllowListingOfUserFolder",
            "Action": [
                "s3:ListBucket"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::<bucket-name>"
            ],
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "home/john/*"
                    ]
                }
            }
        },
        {
            "Sid": "AllowAllS3ActionsInUserFolder",
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::<bucket-name>/home/john/*"
            ]
        }
    ]
}

Yarkon respects the standard AWS substitution for a user name ${aws:username}, so it you have AWS user names defined for the users, you can use a single policy to handle all users. And that’s pretty cool.

Shared bucket for B2B

This is an advanced IAM policy – use only if you have good working knowledge of IAM.

Suppose you are using Yarkon for your business and your end users work for vendors that are clients of yours. You want to have all your vendors using a single bucket named acme-vendors, with each having their own folder in it, but without allowing one vendor to see, or even know, about any other vendor.

While completely fulfilling this requirement is actually not possible with IAM – as any experienced AWS IAM administrator would tell you – it is definitely possible with Yarkon, thanks to the extra policy processing handled by the Yarkon server application. To illustrate how this would be done, consider the following sample structure:

  • acme-vendors (bucket)
    • acme-vendor-east (folder)
      • CT (folder)
      • NJ (folder)
      • NY (folder)
    • acme-vendor-central (folder)
      • CO (folder)
      • KY (folder)
      • TX (folder)
    • acme-vendor-west (folder)
      • CA (folder)
      • OR (folder)
      • WA (folder)

And suppose you need the following roles defined:

  • An administrator user to manage all vendors, with full access to all folders.
  • An administrator user for each vendor, with full access to the vendor folder and its sub-folders.
  • An end user for each vendor, with limited read only access to the vendor folder and its sub-folders.

The following policies will get the job done (shown for acme-vendor-east only, it is similar for the others).

The policy for the system administrator:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowUserToSeeLocationOfBucket",
            "Action": [
                "s3:GetBucketLocation"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::acme-vendors"
            ]
        },
        {
            "Action": "s3:ListBucket",
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::acme-vendors"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::acme-vendors/*"
            ]
        }
    ]
}

The policy for the vendor’s administrator:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowUserToSeeLocationOfBucket",
            "Action": [
                "s3:GetBucketLocation"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::acme-vendors"
            ]
        },
        {
            "Sid": "AllowRootAndHomeListingOfVendorsBucket",
            "Action": "s3:ListBucket",
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::acme-vendors",
            "Condition": {
                "StringEquals": {
                    "s3:prefix": "acme-vendor-east/",
                    "s3:delimiter": [
                        "/"
                    ]
                }
            }
        },
        {
            "Sid": "AllowListingOfUserFolder",
            "Action": [
                "s3:ListBucket"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::acme-vendors"
            ],
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "acme-vendor-east/*"
                    ]
                }
            }
        },
        {
            "Sid": "AllowAllS3ActionsInUserFolder",
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::acme-vendors/acme-vendor-east/*"
            ]
        }
    ]
}

The policy for the vendor’s end user:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowUserToSeeLocationOfBucket",
            "Action": [
                "s3:GetBucketLocation"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::acme-vendors"
            ]
        },
        {
            "Sid": "AllowRootAndHomeListingOfVendorsBucket",
            "Action": "s3:ListBucket",
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::acme-vendors",
            "Condition": {
                "StringEquals": {
                    "s3:prefix": "acme-vendor-east/",
                    "s3:delimiter": [
                        "/"
                    ]
                }
            }
        },
        {
            "Sid": "AllowListingOfUserFolder",
            "Action": [
                "s3:ListBucket"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::acme-vendors"
            ],
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "acme-vendor-east/*"
                    ]
                }
            }
        },
        {
            "Sid": "AllowReadOnlyS3ActionsInUserFolder",
            "Effect": "Allow",
            "Action": [
                "s3:head*",
                "s3:get*"
            ],
            "Resource": [
                "arn:aws:s3:::acme-vendors/acme-vendor-east/*"
            ]
        }
    ]
}

Note that the Yarkon Web Application, when used by an end user that belongs to this vendor, will see the folder acme-vendor-east as the root, and not the bucket.

You can use these policies as a basis for more advanced variations of this approach.

Set up the provider in Yarkon

The first step is to set up the proper connection information for your provider. Use the Yarkon Admin Console, Administration page, Provider tab to specify the below details:

  • Check the S3 Compatible radio option.
  • Enter a Name for your provider. It can be any name, and will be displayed to your end users in the client interface.
  • Select the Region from the drop down. Make sure to choose your Wasabi region, it does not support all regions available with AWS S3.
  • Optionally add an Image for your provider. It will be shown to the end users in the client interface. Acceptable image format is any public URL, or a CSS/data:image compatible format such as svg+xml etc. See below for the recommended image.
  • Specify the End Point for Wasabi. For the default Wasabi region, it is https://s3.wasabisys.com.
  • Specify the IAM End Point and the STS End Point for Wasabi. Use https://iam.wasabisys.com for both.

Wasabi uses the same end point for its IAM and STS compatible services, and specifying it here is required. Make sure to match your Wasabi provider IAM and STS end points to what is specified in this document.

The below image shows how the Yarkon Admin Console page would look when set up with Wasabi.

Wasabi Image:

data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIxMzciIGhlaWdodD0iMTM2IiB2aWV3Qm94PSIwIDAgMTM3IDEzNiI+CiAgPHBhdGggZmlsbD0iIzAzQzczNiIgZmlsbC1ydWxlPSJldmVub2RkIiBkPSJNMTAwLjc3NjQsMTEzLjMzNSBMMTAwLjc3NjQsOTUuNzUzIEwxMTAuNDY5NCwxMDQuNTQxIEMxMDcuNTk1NCwxMDcuODM1IDEwNC4zNDI0LDExMC43OSAxMDAuNzc2NCwxMTMuMzM1IEwxMDAuNzc2NCwxMTMuMzM1IFogTTYwLjE1NzQsMTIzLjAzMiBMODguNTk3NCw5Ni4xNDggTDg4LjU5NzQsMTE5LjkxMSBDODIuMzY1NCwxMjIuMzMgNzUuNTk0NCwxMjMuNjYgNjguNTE4NCwxMjMuNjYgQzY1LjY3NjQsMTIzLjY2IDYyLjg4NTQsMTIzLjQ0NSA2MC4xNTc0LDEyMy4wMzIgTDYwLjE1NzQsMTIzLjAzMiBaIE0xMy4xNjM0LDczLjg0IEw0My4wNDU0LDEwMC42MzcgTDczLjA4NzQsNzIuNDI1IEw4OC41OTc0LDU3Ljc2NCBMODguNTk3NCw3OS4zODkgTDQ2LjU0OTQsMTE5LjEzNyBDMjguNDU3NCwxMTEuMzM1IDE1LjI5NzQsOTQuMjA2IDEzLjE2MzQsNzMuODQgTDEzLjE2MzQsNzMuODQgWiBNMzYuNzg4NCwyMi4yOTYgTDM2LjgwNzQsMzkuOTY4IEwyNi45MDA0LDMxLjA4NCBDMjkuODM0NCwyNy43OCAzMy4xNTM0LDI0LjgyOCAzNi43ODg0LDIyLjI5NiBMMzYuNzg4NCwyMi4yOTYgWiBNMzYuODQ4NCw3OC43MjEgTDEzLjc1NjQsNTguMDE0IEMxNC44NTU0LDUxLjk3OCAxNi45MzE0LDQ2LjI3OSAxOS44MTI0LDQxLjA4NiBMMzYuODI0NCw1Ni4zNDIgTDM2Ljg0ODQsNzguNzIxIFogTTc3LjAyMTQsMTIuOTg5IEw2NC40NTc0LDI0Ljg2NSBMNDguOTg1NCwzOS41MzkgTDQ4Ljk2MTQsMTUuODkgQzU1LjA0ODQsMTMuNTk4IDYxLjYzODQsMTIuMzQgNjguNTE4NCwxMi4zNCBDNzEuNDA4NCwxMi4zNCA3NC4yNDg0LDEyLjU2MiA3Ny4wMjE0LDEyLjk4OSBMNzcuMDIxNCwxMi45ODkgWiBNMTIzLjMxNDQsNzcuODAxIEMxMjIuMjU2NCw4My43MjkgMTIwLjI1NzQsODkuMzM0IDExNy40Nzg0LDk0LjQ1NyBMMTAwLjc3NjQsNzkuMzE0IEwxMDAuNzc2NCw1Ny4zNjggTDEyMy4zMTQ0LDc3LjgwMSBaIE0xMjMuODM1NCw2MS44MzUgTDk0LjYwMDQsMzUuMzMgTDY0LjczNTQsNjMuNTYxIEw0OS4wMjY0LDc4LjMxMyBMNDkuMDAzNCw1Ni4zMDggTDcyLjgzMTQsMzMuNzA5IEw5MC42MDA0LDE2LjkxMiBDMTA4LjUzNzQsMjQuNjk1IDEyMS42MDE0LDQxLjY1NSAxMjMuODM1NCw2MS44MzUgTDEyMy44MzU0LDYxLjgzNSBaIE0xMTYuNDg3NCwyMC4wMyBDMTAzLjY3NDQsNy4yMTcgODYuNjM4NCwwLjE2MSA2OC41MTg0LDAuMTYxIEM1MC4zOTc0LDAuMTYxIDMzLjM2MTQsNy4yMTcgMjAuNTQ4NCwyMC4wMyBDNy43MzU0LDMyLjg0MyAwLjY3OTQsNDkuODc5IDAuNjc5NCw2OCBDMC42Nzk0LDg2LjEyMSA3LjczNTQsMTAzLjE1NyAyMC41NDg0LDExNS45NyBDMzMuMzYxNCwxMjguNzgzIDUwLjM5NzQsMTM1LjgzOSA2OC41MTg0LDEzNS44MzkgQzg2LjYzODQsMTM1LjgzOSAxMDMuNjc0NCwxMjguNzgzIDExNi40ODc0LDExNS45NyBDMTI5LjMwMDQsMTAzLjE1NyAxMzYuMzU3NCw4Ni4xMjEgMTM2LjM1NzQsNjggQzEzNi4zNTc0LDQ5Ljg3OSAxMjkuMzAwNCwzMi44NDMgMTE2LjQ4NzQsMjAuMDMgTDExNi40ODc0LDIwLjAzIFoiLz4KPC9zdmc+Cg==@

Add users to Yarkon

Any end user that needs access to S3 buckets using Yarkon, must be added to the system. Users who are not added to the system, or are not in status active, cannot log in to Yarkon. This allows the administrator to immediately revoke a user’s access as needed.

Adding Users

To add end user accounts, use the Users section from the left navigation pane, then click the Add button and fill in the details of each user. When using the Integrated or Federated Security Models, you also have to specify the IAM name, group or role through which permissions are granted to the end user. This is not required if you use the simpler Shared Security Model.

A random password can be generated by the system, or a password can be set by the administrator. The credentials will be communicated to the user using the email entered as the username.

Strong passwords can be enforced using the Administration page, Identity tab.

Import users

Yarkon also supports bulk import of users, using a standard CSV (comma delimited) file. Simply use the Upload button from the Users form. The format is described in the user interface.

When users are being added in bulk, welcome emails will not be sent. Instead, Yarkon will set up all user accounts added in bulk with the password “Password” (the word password, with the P capitalized). The administrator should communicate this place holder password to the end users. They will be required to change their password on first login.

Customize the look and feel

Using Yarkon, you can customize the appearance, content and features available to the client application.

Branding

Yarkon Cloud supports branding (AKA, “white labeling”) of the Yarkon client application. Use the Branding form to define your theme, and see how the client would look like using the available preview. Once you are done, click the Update Active Theme button.

Your changes will be reflected in the client application when users log in the next time.

For an example of how a branded Yarkon would look like, check out this link.

Branding is not available to FREE tier subscribers.

Bucket display names

One of the issues with S3 is the requirement for bucket names to be globally unique. All the good names are already taken, it seems.

While we cannot change that, Yarkon does allow you to define a Display Name for your buckets, which will be shown in the UI instead of whatever S3 made you name the bucket. Use the Buckets form to enable this feature, then set the display name for any bucket listed.

Features

By default, there are a number of features that the Yarkon Client supports, but are disabled. For instance, some advanced bucket actions, such as tagging or changing logging are not available to end-users. If in your organization you prefer to allow some or all of these extra capabilities to your end users, use the Features form to enable them. Once you are done, click the Apply Changes button.

Your changes will be reflected in the client application when users log in the next time.

If after following these steps you are still having issues getting your server to run, please contact us.