NOTE: This article describes a process that is no longer supported. It is maintained solely for legacy reference purposes.
If you want to use the Amazon Web Services (AWS) S3 connector in the Share and Deploy console to share experiences with other users or to deploy them remotely, it is highly recommended that you create a dedicated user on AWS.
Initial setup of you AWS/S3 bucket
For security reasons this dedicated user should only have the right to read, write and delete the content of one AWS/S3 bucket. You (or someone from your IT Department) should be comfortable with AWS principles and you should already have an AWS account.
They are many ways to create such a user with the correct rights. A simple method is the following:
- in AWS/S3
- create a dedicated bucket, named for example myBucket, in the nearest AWS region.
- select the newly created bucket, select "Permissions", click on "Block public access", select "Edit", and then block all public access. This is extremely important as it will prevent information leakage.
- then in AWS/IAM
- create a new dedicated user, named for example myUser. Select Programmatic Access as unique Access type. Record this new account's ID and Access Key credentials, which look like very long random strings. Example :
- Access Key ID: AKIAI6ZYK6YWFLMEGELA
- Secret Key: R7tA7fKzVb+fHe9WEDZQC9VVxjWvDf3e2halu3qt
- create a new dedicated group, named for example myGroup. Give this group the rights to "DeleteObject", "GetObject", "ListBucket", and "PutObject".
- This can be done in AWS/IAM by using the Policy Generator when creating the new group. In the Policy Generator, select the service "AWS S3", select the actions mentioned above, and apply them to two Amazon Resource Names: arn:aws:s3:::myBucket and arn:aws:s3:::myBucket/*.
- You can also do it by typing the following policy in the editor available via "Inline Policies" -> "Create Group Policy" -> "Edit Policy":
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt1396513442000", "Effect": "Allow", "Action": [ "s3:DeleteObject", "s3:GetObject", "s3:ListBucket", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::myBucket/*", "arn:aws:s3:::myBucket" ] } ] }
- You can also do it by typing the following policy in the editor available via "Inline Policies" -> "Create Group Policy" -> "Edit Policy":
- This can be done in AWS/IAM by using the Policy Generator when creating the new group. In the Policy Generator, select the service "AWS S3", select the actions mentioned above, and apply them to two Amazon Resource Names: arn:aws:s3:::myBucket and arn:aws:s3:::myBucket/*.
- create a new dedicated user, named for example myUser. Select Programmatic Access as unique Access type. Record this new account's ID and Access Key credentials, which look like very long random strings. Example :
- Finally, in AWS/IAM, add the user (myUser in this example ) to the newly created group (myGroup in this example ).
Enter these user credentials and the bucket in the Storage Settings panel of the Share and Deploy console as illustrated in the following figure. Your settings will be different from what you see below.
Enhancing security by restricting access to your AWS S3 bucket
If all of your Players and Composers are located on a LAN with one or several well-known IP addresses, it is possible to restrict bucket access to those addresses. With such a restriction, no one, even the Intuiface Support team, can access your published experiences. This is guaranteed by the AWS S3 security policy you will have invoked.
Before restricting access to the bucket you created, proceed as indicated above, and try at least once to publish a simple Intuiface experience. If the publish attempt is successful, you may add the IP address restriction. IP address restriction will not affect any Share and Deploy feature.
Follow these steps to restrict access:
- From your AWS console, select the S3 service
- click on the S3 bucket myBucket you created
- click on Permissions
- click on Bucket Policy
- in the text field, enter the following policy:
{
"Version": "2012-10-17",
"Id": "S3PolicyId1",
"Statement": [
{
"Sid": "IPAllow",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::myBucket/*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
IPv4Address1,
IPv4Address2
]
}
}
}
]
}
You may use IPv4 addresses (ex: "43.76.12.168"), or IPv4 CIDR ranges (such as "43.76.12.168/29"), or IPv6 CIDR (such as "2001:DB8:1234:5678:ABCD::/80"). This setup also works for Composers or Players located outside of your LAN if you have a properly configured VPN.
Be sure to check your configuration:
- a Composer with a public, authorized IP address must be able to publish an experience and download (a previously uploaded) experience
- a Composer with a public, unauthorized IP address must fail to upload or download an experience.
You may also use other access restrictions by following the AWS S3 bucket policy documentation and bucket policy examples.
Limitations:
- If you share an experience with anyone, their Composers / Players must be located on the same LAN (or use your VPN).
- From within the Share and Deploy Console, you won't be able to verify that your S3 storage is properly configured. (Configuration and publishing would not be possible unless configuration was successful so this lack of information isn't much of a problem.)
- As of Intuiface Version 6.5.5, error messages displayed by Intuiface Player or Composer on a device unauthorized to access the AWS/S3 Bucket may not be fully explicit. These messages will be enhanced in future versions of Player and Composer.
- If a Composer user with a copy of an experience were to edit and publish it while using an unauthorized IP address, the experience will be considered as corrupted in the Share and Deploy Console. The experience would have to be published again from a device with an authorized IP address. (The typical case is a user who forgot to activate his/her VPN before publishing an experience).
Comments
0 comments
Article is closed for comments.