The following table explains the differences between them:
Yarkon gets its permissions based on a Principal AWS IAM entity. This entity is:
|Model||Principal||How to assign|
End users, using the Yarkon Client Application, get their permissions from AWS IAM entities as well, as following:
|Model||End users permissions||How to assign|
|Shared||Same as Principal||Automatic, no action needed|
|Federated||Based on IAM user, group or role||Associate user with permissions using Yarkon Server.|
|Integrated||Based on IAM user, group or role||Associate user with permissions using Yarkon Server.|
Important: End users only get S3 permissions. No other AWS service permissions are ever exposed to end users.
As you can see in the above, there are few ways of setting up the server, 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.
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 Server, and should be the same for all.
Follow these steps:
The most generic policy – that is, one that would work for all security models – is:
In all policies shown here, make sure to replace the
<account-number>with your AWS account number. Your AWS account number is a 12 digit account ID. See this document from Amazon in case you do not have this ID handy.
Details (see the
Sid attributes for reference):
AllowAllS3Actions – allows the Yarkon Server 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:
AllowUIToDisplayIAMOptions – only required when using Federated or Integrated security models.
The Yarkon Server 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. 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.
AllowTheRoleToFederate – only required when using the Federated security model. You can remove it if using any of the other models.
AllowUsingSESForEmail – only required if you intend to use Email integration, and would be using AWS SES as your mail server. If you do not intend to integrate Yarkon Server with an email server, or will be using a standard SMTP server, you can remove this section.
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
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*" ].
When using an EC2 instance, if you can run it with a IAM role, it is the simplest and most secure way – because no API credentials are required, hence there is no risk these credentials would be compromised.
When you launch the instance, make sure to associate the aforementioned Yarkon IAM role just created with the instance. For more on IAM IAM roles, read this document from Amazon.
If you are using an EC2 instance, but cannot associate it with the Yarkon IAM role, follow the instructions below for the setup for Non EC2 server.
The next and final step is to create the IAM role:
AllowAssumeRoleis what was added):
Launch the EC2 instance with this IAM role.
When using a unix server (or an EC2 instance without an IAM role), credentials are provided to the application using the environment.
Important: The AWS 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.
You will only need to use these access credentials once, during the set up of Yarkon, as described later on in this guide.
The first step is to get these credentials.
Next, you want to present the credentials to the running application. There are two ways to accomplish that, choose whichever is simpler for your use case.
~/.aws/credentialsand include the API credentials created. If you are not familiar with AWS credential files, follow this document from Amazon.
When using a docker container, if possible, you want to set the IAM role at the container level. If this is the case, then it would behave exactly like the aforementioned EC2 instance with an IAM role.
If you cannot set an IAM role for your docker container, credentials are provided to the container in a similar manner to the aforementioned Non EC2 server, so acquire the API credentials in the same way. Once you have them, pass them to the container just like you would any other
The following example shows how to accomplish this task using a standard