LOG IN SIGN UP
Documentation

Microsft Azure Blob Storage

  Last updated October 03, 2018

Microsoft Azure Blob Storage public and private containers can be used as origins with Fastly.

Using Azure Blob Storage as an origin

To make your Azure Blob Stores available through Fastly, follow the steps below.

Creating a new service

Follow the instructions for creating a new service. You'll add specific details about your origin when you fill out the Create a new service fields:

Setting the default host and correct path

Once the new service is created, set the default host to azure and then add your container path to the URL by following the steps below:

  1. From the service menu, select the appropriate service.
  2. Click the Configuration button and then select Clone active. The Domains page appears.
  3. Click the Settings link. The Settings page appears.
  4. Click the Override host switch. The Override host header field appears.

    the Add an override host header window

  5. Type the hostname of your Azure Blob Storage account. For example, <storage account name>.blob.core.windows.net.

  6. Click the Save button. The new override host header appears in the Override host section.
  7. Click the Content link. The Content page appears.
  8. Click the Create header button. The Create a header page appears.
  9. Fill out the Create a header fields as follows:
    • In the Name field, type Modify URL.
    • From the Type menu, select Request, and from the Action menu, select Set.
    • In the Destination field, type url.
    • In the Source field, type "/<your container name>" req.url.
    • From the Ignore if set menu, select No.
    • In the Priority field, type 10.
  10. Click the Create button. The new Modify URL header appears on the Content page.
  11. Click the Activate button to deploy your configuration changes.

Testing your results

By default, we create DNS mapping called yourdomain.global.prod.fastly.net. In the example above, it would be cdn.example.com.global.prod.fastly.net. Create a DNS alias for the domain name you specified (e.g., CNAME cdn.example.com to global-nossl.fastly.net).

Fastly will cache any content without an explicit Cache-Control header for 1 hour. You can verify whether you are sending any cache headers using cURL. For example:

$ curl -I opscode-full-stack.blob.core.windows.net

HTTP/1.1 200 OK
Date: Fri, 04 May 2018 21:23:07 GMT
Content-Type: application/xml
Transfer-Encoding: chunked
Server: Blob Service Version 1.0 Microsoft-HTTPAPI/2.0

In this example, no cache control headers are set so the default TTL will be applied.

Using an Azure Blob Storage private container

To use an Azure Blob Storage private container with Fastly, follow the instructions below.

Before you begin

Be sure you've already made your Azure Blob Storage containers available to Fastly by pointing to the right container and setting your origin to port 443. This needs to be done before authenticating.

Be sure you've got your Azure Storage Account shared key, Storage account name, and blob container name on hand. The Azure Blob Storage Authorization header takes the following form:

  Authorization: SharedKey `_Account name_`:`_Signature_`

You'll need the following information from your developer Azure account:

  1. The Azure Storage Account shared key. This is available in your Storage Account portal under "Settings -> Access keys".
  2. Your Storage Account name.
  3. Your Blob container name.

Setting up Fastly to use an Azure Blob Storage private container

In order to use an Azure Blob Storage private container with Fastly, create two headers, a Date header (for use with the authorization Signature) and an Authorization header.

Create a Date header

  1. Log in to the Fastly web interface and click the Configure link.
  2. From the service menu, select the appropriate service.
  3. Click the Configuration button and then select Clone active. The Domains page appears.
  4. Click the Content link. The Content page appears.
  5. Click the Create header button. The Create a header page appears.

    creating a date header via the header page

  6. Fill out the Create a header fields as follows:
    • In the Name field, type Date.
    • From the Type menu, select Request, and from the Action menu, select Set.
    • In the Destination field, type http.Date.
    • In the Source field, type now.
    • From the Ignore if set menu, select No.
    • In the Priority field, type 10.
  7. Click the Create button. A new Date header appears on the Content page. You will use this later within the Signature of the Authorization header.

Create an Authorization header

Next create the Authorization header with the specifications listed below.

  1. Click the Create header button again to create another new header. The Create a header page appears.

    creating an authorization header via the header page

  2. Fill out the Create a header fields as follows:
    • In the Name field, type Azure Authorization.
    • From the Type menu, select Request, and from the Action menu, select Set.
    • In the Destination field, type http.Authorization.
    • From the Ignore if set menu, select No.
    • In the Priority field, type 20.
  3. In the Source field, type the header authorization information using the following format:

    "SharedKey <Storage Account name>:" digest.hmac_sha256_base64(digest.base64_decode("<Azure Storage Account shared key>"), if(req.method == "HEAD", "GET", req.method) LF LF LF req.http.Date LF "/<Storage Account name>" req.url.path)
    

    replacing <Storage Account name> and <Azure Storage Account shared key> with the information you gathered before you began. For example:

    "SharedKey test123:" digest.hmac_sha256_base64(digest.base64_decode("UDJXUFN1NjhCZmw4OWo3MnZUK2JYWVpCN1NqbE93aFQ0d2hxdDI3"), if(req.method == "HEAD", "GET", req.method) LF LF LF req.http.Date LF "/test123" req.url.path)
    
  4. Click the Create button. The new Authorization header appears on the Content page.

A detailed look at the Source field

So what's going on in the Source field of the Authorization header? Here's the basic format:

SharedKey<storage account name><Signature Function><key><message>

It tells us the following:

Element Description
SharedKey A constant placed before the storage account name. It's always SharedKey.
storage account name The name of your Azure Storage Account. We used test123 in this example.
signature function The algorithm used to validate the key and message of the signature. We used digest.hmac_sha256_base64(<key>, <message>) in this example.
key The Azure Storage Account shared key from your Azure Storage developer's account. We used UDJXUFN1NjhCZmw4OWo3MnZUK2JYWVpCN1NqbE93aFQ0d2hxdDI3 in this example. It must be Base64 decoded.
message The UTF-8 encoding of the StringToSign. See the table below for a break down of each portion of the message.

The message that's part of the Source field in the Authorization header takes on this basic format:

<HTTP-verb></n><Content-MD5>/n<Content-Type></n><Date></n><CanonicalizedAmzHeader></n><CanonicalizedResource>

It tells us the following:

Element Description
HTTP-verb The REST verb. We use req.method in this example. We rewrite HEAD to GET because Varnish does this internally before sending requests to origin.
\n A newline indicator constant. It's always \n.
Content-MD5 The content-md5 header value, used as a message integrity check. It's often left blank. We use LF (line feed) in this example.
Content-Type The content-type header value, used to specify the MIME-type. It's often left blank. We use LFin this example.
Date The date and time stamp. We use req.http.Date (which we created first as a separate header in the steps above).
CanonicalizedHeaders The x-ms headers, which customize your Azure Blob Storage implementation. It's often left blank. We use LF in this example.
CanonicalizedResource Your Storage Account Name. We use "/test123" in this example.
This article describes an integration with a service provided by a third party. Please see our note on integrations.

Back to Top