Security models

Starting with Version 3.0, all editions of Yarkon support three security models: Shared, Federated, and Integrated.

It is recommended that you start using Yarkon with the Shared Security Model, as it is much simpler to get up and running. You can later migrate to the more complex Federated Security Model or Integrated Security Model, which require a deeper understanding of the AWS IAM permission system.

You can always change the security model using the Yarkon Admin Console Administrator settings:

Before getting into the Security Models available, it is important to understand how Yarkon gets its security credentials to access S3 and other essential AWS services such as STS and IAM.

Shared hosting

When Yarkon is used as a Shared Hosting solution, such as a monthly subscription to Yarkon Cloud, credentials are provided to Yarkon using the Access tab of the Admin settings page, accessible to the system administrator only through the Yarkon Admin Console interface. These credentials belong to a dedicated IAM user, used to provide Yarkon with the appropriate permissions. For more, see the IAM Policies page.

Private hosting

When Yarkon is used as a Private Hosting solution, such as Yarkon Server, credentials are provided to Yarkon in the standard AWS way - the most secure way is to define a "Machine Role", then run the instance under this role, which will in turn provide the credentials to the application. This is the preferred approach as it does not require putting in credentials anywhere, so if your AWS VPC is somehow compromised, you have no exposure. Note that this approach can be used also for docker based instances. For the complete guide on how to utilize this approach, review the documentation from Amazon. Alternatively, if for whatever reason you cannot provide role credentials - the most notable case would be Federated Security where you would like to control a different AWS account - you can pass in credentials to Yarkon using an AWS config file. For more details on how to do so, check out the documentation from Amazon.

High level comparison

The following table describes the differences between the security models available:

Security Model	Description	Use Case
Shared Security	All end users have the same S3 permissions. These permissions are defined by the security credentials provided to Yarkon, through an IAM user.	This model is most applicable for smaller organizations where all users have the same access level. Another common use case is when setting up Yarkon on a departmental level, and all users are granted similar permissions.
Integrated Security	Different users have different S3 permissions. You can define user access at the user, group or role level.	This model is most applicable for larger organizations where users have specific permissions, based on their job requirements. Another common use case is when Yarkon is used to provide access to external users that should have limited access compared to internal users.
Federated Security	Different users have different S3 permissions. You can define user access at the user, group or role level.	This model is most applicable for larger organizations where users have specific permissions, based on their job requirements. A common use case is when Yarkon is used as a Private Hosting solution and you want to control a AWS account that is not the same as the one where the instance is running.

Shared Security Model

When using the Shared Security Model, all users have the same access permissions, as defined by the permissions given to the Yarkon Admin Console through the AMI AWS Role (when using Yarkon Server) or the AWS API credentials (when using Yarkon Cloud).

This security model is simple and easy to set up, as it does not require creating any users in IAM. Users can be added and removed through the Yarkon Admin Console without any need to use the AWS IAM service. It is sufficient for any organization that has a "flat" access model, meaning that all users can access the same files. For instance, this is common for organizations where S3 is used for storing documentation that is accessible to all employees without restrictions, such as company policies, user manuals, etc.

If you need to specify access per user, with different users having access to different buckets, you must use the Integrated Security Model instead.

To learn how to add users to Yarkon, check out the document Adding the users to Yarkon and verifying that the proper permissions are set.

Integrated Security Model

The Integrated Security Model, Yarkon takes it permissions from IAM and ensures that users only get access to the bucket that they are allowed to access. This is the approach preferred by most enterprise clients, as it allows to manage user permissions in one place and ensure that different users get the appropriate permissions.

In case you want to use the Integrated Security Model, you need to have your organization set up in IAM. An example of such an organization is provided here: Setting up the users in AWS and granting them permissions to access buckets using Groups and Policies.

Once the permissions are properly set in AWS IAM, all that it takes is to integrate the users in Yarkon with their respective AWS IAM users. Check out the document Adding the users to Yarkon and verifying that the proper permissions are set for the complete details.

Federated Security Model

The Federated Security Model is similar to the Integrated, and effectively accomplishes the same results.

When using Yarkon as a Private Hosting solution, use the Federated Security Model in case you want to manage users in an account different than the one where the Yarkon instance is running, or if you prefer to grant permissions to users using a dedicated IAM user for Yarkon, instead of relying on the machine role used to run the instance.

When using Yarkon as a Shared Hosting solution, it is a matter of preference - you can either provide the credentials to Yarkon using a role, on which case you would use the Integrated Security Model, or through a dedicated IAM user, in which case you would use the Federated security instead.

Detailed comparison

Security Model	Description	Benefits	Challenges
Shared Security	All end users in your account have the same access permissions.	Simple to implement.	Cannot have different permissions for different users.
Federated Security	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. Cannot be on EC2 with IAM role.
Integrated Security	Different users can have different permissions, using IAM users, groups and roles.	Very flexible, complete control over users permissions. Does not require API keys, therefore most secure.	Requires good knowledge of IAM. Must be used on an EC2 with IAM role.

Yarkon gets its permissions based on a Principal AWS IAM entity. This entity is:

Security Model	Principal	How to assign
Shared Security	IAM user with API credentials, or EC2 only, with IAM role	Provide credentials through environment variables, or EC2 only: Run the instance with the IAM role.
Federated Security	IAM user with API credentials	Provide credentials through environment variables, or EC2 only: Run the instance with the IAM role.
Integrated Security	EC2 only, with IAM role	EC2 only: Run the instance with the IAM role.

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

Security Model	End users permissions	How to assign
Shared Security	Same as Principal	Automatic, no action needed
Federated Security	Based on IAM user, group or role	Associate user with permissions using Yarkon Admin Console.
Integrated Security	Based on IAM user, group or role	Associate user with permissions using Yarkon Admin Console.

End users only get S3 permissions. No other AWS service permissions are ever exposed to end users.