The subscription includes a 14 day FREE trial.
The subscription will initiate a stack deployment using an AWS CloudFormation template, creating these stack components.
To set up the Yarkon stack, you need to specify the following:
You can leave all other fields empty. Note that you have to approve the creation of IAM elements by the CloudFormation template – the process creates the IAM role for the EC2 instance.
Please allow the process about 15 minutes to complete, depending on the instance type you chose. You can track the progress in your EC2 Instances dashboard, waiting for the EC2 instance to complete its initialization process.
When done, the setup URL will be displayed in the Outputs section of the stack details. Click it to go to the set up process.
The set up form of Yarkon creates your administrator account. Note that the 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.
At this point, your set up is complete and the Yarkon system is ready to be used. You should see the the overview page of the Yarkon Admin Console application.
Please follow the next section for some necessary and optional configuration.
Yarkon supports two security models:
Yarkon is shipped with the security model set to the simpler Shared Security Model, allowing you to verify the install right away. However, for data security reasons, users of the Enterprise Edition should alway use the Integrated Security Model, with fine grain control over user access to the S3 resources. This model ensures that access to S3 is always proactively set by the administrator using IAM, and no permission might be granted inadvertently. For this reason, make sure to update the security model before you start adding users.
For more details about Yarkon security models, see the Security Models document.
For users to be able to access the application, you need to provision a proper DNS name, using your registrar.
The process might be slightly different depending on the registrar you use for your domain names; in case you use AWS Route53 to manage your domains, as most AWS clients do, you will have to assign an A record for the load balancer url, like shown in the image.
Next you’d need to ensure only secure HTTP traffic can access the Yarkon Application. For that you’d need an SSL certificate that matches the DNS name you created before, or a star (*) certificate that matches the domain.
From the AWS EC2 Dashboard, choose the elastic load balancer created for Yarkon. Add an HTTPS listener, allowing traffic from the internet through port 443 to port 80 on the EC2 instance, and set the certificate for this route to be the aforementioned.
Once you confirmed that it is working, you should remove the default HTTP (port 80) that was created for you by the CloudFormation template – it is no longer needed.
Cross-origin resource sharing (CORS) defines a way for client web applications that are loaded in one domain to interact with resources in a different domain.
It is important to understand that the ACLs and policies continue to apply when you enable CORS on the bucket. Changing the CORS rules for a bucket does not have any impact on its ACL and policies.
Using the Buckets view, start with analyzing the CORS status. Select all buckets using the checkbox selector, and click the Analyze CORS button. After you determined which buckets require update, select those only, and click the Update CORS button. In the pop-up form, specify the origin you want to set – or accept the default – and approve the change.
For more info about CORS, see this document.
Yarkon supports optional email integration. The email service is used to enable self-management of account by end users. In case a user forgets her password, she can reset her password using the client application, and receive a newly created auto-generated temporary password to her email inbox. Also, when a new user is added to the system, a welcome email with the credentials and login url will be automatically sent.
If you do not set up the email integrations, users would not be able to reset their password, and you will have to communicate the account credentials to the end user upon account creations. Otherwise, there is no impact – users can always change their password on their own.
Yarkon can work with any SMTP email server, as well as with AWS SES email service. Use the Administration EMail form to set up your email integration. In the images below you can see a sample for how email is setup with an SMTP server as well as with the AWS SES Service.
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 Security Model, as we do in this guide, you 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. If email integration is enabled, the credentials will be communicated to the user using the email entered as the username. Otherwise, the administrator has to communicate the password to the newly created user.
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, and even if you have email integration set up, welcome emails will not be sent. This is to protect your account from being flagged by your email provider as spammer; while this is not common, it might happen when using some providers who limit the rate of email sends.
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.
Using Yarkon, you can customize the appearance, content and features available to the client application.
The Enterprise Edition of Yarkon 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 refresh their screen the next time.
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 now allows 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 from to enable this feature, then set the display name for any bucket list.
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. 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.