Amazon S3 with authorization¶
Table of Contents
When using Remote Storage as for instance with Amazon S3, it might be needed to secure access to the S3 buckets used instead of using ‘public’ access. This means that there will be no anonymous access, but also that the requests to the content in the bucket needs to be authenticated.
There are two ways to do this:
- use the Authorization header
- send a signature as a URL-encoded query-string parameter.
The following examples will use the second method.
More information can be found in Amazon’s Authenticating Requests documentation.
AWS Signature v4¶
New in version 1.7.29.
As of January 30, 2014, newer AWS regions such as eu-central-1 require the use of the AWS Signature v4 for authentication. To enable the use of v4 signatures the name of the S3 region must be set when configuring access to the bucket. If the region is set, v4 signatures will be used whether or not the region requires it. Not setting the S3 region will result in USP using the older v2 sigature method that may not be supported by all regions.
Using webserver directives for S3 authentication¶
New in version 1.7.2.
It is possible to use webserver directives and let USP sign the request automatically with the following webserver directives.
This covers one specific use case: both content (mp4/ismv) and server manifest (ism) are placed in the S3 bucket and the manifest references the content locally (no paths or URLs, just the filename).
The directives for Apache are the following:
Option | Description |
---|---|
S3SecretKey | The AWS secret key. |
S3AccessKey | The AWS access key. |
S3Region | Region of bucket where data is stored, added in 1.7.29. Required for AWS Signature v4. |
The directives for Nginx are the following:
Option | Description |
---|---|
s3_secret_key | The AWS secret key. |
s3_access_key | The AWS access key. |
s3_region | Region of bucket where data is stored, added in 1.7.29. Required for AWS Signature v4. |
The keys can be created in the AWS IAM portal and managed there as well (active/inactive, delete).
There is one limitation, the directives need to be placed in a location mapping to the directory that is setup to use IsmProxyPass.
The reason for this lays in Apache’s handle chain where Directory
is
processed differently from Location
so the S3 keywords are not available
when placed in Directory
.
Apache example¶
<Location "/s3_auth">
S3SecretKey SECRET_KEY
S3AccessKey ACCESS_KEY
S3Region BUCKET_REGION
</Location>
<Directory "/var/www/test/s3_auth/auth-remote-manifest/">
IsmProxyPass http://unified-streaming-auth.s3-eu-west-1.amazonaws.com/
</Directory>
An explanation of the parts of the paths used in Location and Directory:
Path | Description |
---|---|
/var/www/test | The document root |
/s3_auth | The location mapping applying the S3 directives |
/auth_remote_manifest | The directory that maps IsmProxyPass into place |
The following curl call will return the client manifest created from the securely fetched server manifest.
curl -v http://test.unified-streaming.com/s3_auth/auth-remote-manifest/oceans.ism/manifest
Playout will follow the same pattern: Apache will translate the request into S3 and apply the signature.
Nginx¶
With Nginx, a Directory
directive in the virtual host is not needed, a location will suffice.
location ^~ /s3_auth/auth-remote-manifest/ {
s3_secret_key SECRET_KEY;
s3_access_key ACCESS_KEY;
s3_region BUCKET_REGION;
ism_proxy_pass http://unified-streaming-auth.s3-eu-west-1.amazonaws.com/;
usp_handle_ism;
}