The following table explains the differences between them:
End users, using the Yarkon Client Application, get their permissions from AWS IAM entities as following:
|Model||End users permissions||How to assign|
|Shared||Same for all||Automatic, no action needed|
|Federated||Based on IAM user, group or role||Associate user with permissions using Yarkon Cloud.|
|Integrated||Based on IAM user, group or role||Associate user with permissions using Yarkon Cloud.|
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, 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 Cloud, 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 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:
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.
AllowTheRoleToFederate – only required when using the Federated security model. You can remove it if using any of the other models.
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*" ].
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.
To create the IAM role:
AllowAssumeRoleis what was added):
Yarkon Cloud is using AWS API credentials (often referred to as “access keys”) to integrate with AWS. This final step will generate these credentials.
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.
To get these 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.