Attaching Cloud Storage to Your AoC Organization

You can attach existing cloud storage to your AoC organization using the Aspera transfer service available in Aspera on Cloud.

This procedure describes how to add the storage types below:
  • Microsoft Azure Blob
  • Google Cloud
  • IBM Cloud Object Storage
To add an AWS S3 bucket, see Attaching an AWS S3 Bucket

Once you attach the storage, you can create access keys to enable Aspera transfers to and from the cloud storage. The storage is then available to support your organization workspace(s). You can make content in the storage available to your AoC users in the form of administratively shared folders (see Sharing a Folder with a Workspace).

This procedure also creates access keys to the cloud storage that you can share with other users so that they can run Aspera transfers with the cloud storage from any Aspera client application. You can create multiple access keys to the same cloud storage to allow access to different areas of the storage. To do so, repeat the procedure in this topic, creating a transfer service node for each individual access key. The transfer service attaches the cloud storage to your organization and performs the transfers your users request.

Use this procedure when you have existing cloud storage but no Aspera transfer node associated with it, and want to use the transfer service to connect with it. If you already have an existing Aspera transfer node (which can be on-prem or in the cloud, and managed by you or by Aspera) with its Node URL and password, see Tether Your Aspera Transfer Server to Aspera on Cloud.

Note: Once you create the new transfer service node, you can use the Aspera GUI to transfer to the cloud storage; see Using the Transfer Service from the Desktop Client GUI

Prerequisites

Procedure

  1. In the Admin Management console, click Nodes and storage > Nodes > Create new.
  2. Click Attach my cloud storage.

    If you do not see this option at the top of the page, you do not have transfer service admin privileges. You must ask a user who is a transfer service admin to add this privilege to your user profile (go to Users > userName and select ATS admin in the Admin roles section).

  3. Enter a Node name for the transfer service node.

    If you are creating multiple access keys to the same storage for different users or groups of users, make the name descriptive enough to tell them apart.

  4. If a pre-configured network policy is required for this node, click the Network policy field and select the intended policy. For details, see Creating Network Policies.
  5. If a pre-configured node configuration policy is required for this node, click the Configuration policy field and select the intended policy. For details, see Creating Node Configuration Policies.
  6. Select the storage type and enter credentials and specifications relevant to this storage type. The following table provides guidance for certain storage types. For AWS S3 settings, see Attaching an AWS S3 Bucket.
    Storage Type Credentials
    Azure Blob Provide an access key or SAS URL for the storage credentials:
    • Access key:
      • In the Azure portal storage account Access keys page, copy the storage account name; paste that info into the AoC Storage account field.
      • In the Azure portal storage account Access keys page, copy the access key; paste that info into the AoC Access key field.
      • In the Path field, enter / to access the root level, or enter /<pathName> to access a specific folder.
    • SAS URL:
      • Paste the complete URL, with queries, in the Shared access signature field. For example, https://aspera.blob.core.windows.net/?sv=2018-05-22&ss=bfqt&sr=b&sp=rwdlacup&se=2019-07-23T04:56:28Z&st=2019-08-22T20:56:28Z&spr=https&sig-ivlRmKYM2lR1BgaBe1r97KY02RinVnQzKbBnDixgCFg%8J.
      • The SAS URL must contain a query parameter (in the URL, everything after '?').
      • The SAS URL must have more than five parameter items (each parameter item follows '&').
      • The SAS URL must have the following parameters set:
        • sv (&sv=): Storage services version. For storage services version 2012-02-12 and later, this parameter indicates the version to use.
        • se (&se=): Expiry time. Specified in UTC time.
        • sp (&sp=): Permissions. The permission granted by the SAS include Read and Write.
        • sig (&sig=): Signature. Used to authorize access to the blob. The signature is an HMAC computed over a string-to-sign and key using the SHA256 algorithm, and then encoded using Base64 encoding.
        • sr (&sr=): Resource. b = blob. The resource is a blob.
        • st (&st=): Start time. Specified in UTC time.
    • In the Path field, enter / to access the root level, or enter /<pathName> to access a specific folder.
    • For Premium Blob storage, select Page API in the API type field.
    • For Standard Blob storage, select either Page API or Block API.
    • AoC supports writing to storage accounts that have encryption enabled.
      Note: You can enable encryption only on nodes that are not configured for watermarking. See this article for details.
    Google Cloud Provide a private key or OAuth token for authentication. Both require that you create a service account:
    1. Log in to Google Cloud Platform (GCP).
    2. Select the project that contains the storage that you want to add to AoC.
    3. Go to IAM & admin > Service accounts and click Create service account.
    4. Enter a Service account name, such as "ats-google-bucket_name-access". If desired, edit the Service account ID.
    5. Select the Project role. The minimum role required for Aspera to access the storage is Storage Object Admin.
    6. To use Private key authentication, select Furnish a new private key and leave JSON selected for the key type.
    7. Click Save. If you created a private key, store it according to local site practice.
    8. The private key ID is now listed in the table.

    To use Private key authentication:

    1. In the GCP console, copy the project ID (for example, "test-project-1234") and paste it into the Project ID field in the AoC UI.
    2. In the GCP console, copy the private key ID that is listed in the Service account keys table (for example, "4g444gd311ff277d34722gcgc5fbd51795b56fg4") and paste it into the Private key ID field in the AoC UI.
    3. Open the private key that you saved to your computer, copy the value for "private_key".
      For example:
      -----BEGIN PRIVATE KEY-----
MB91dowSoh\\nyUtv...Ttzr9u3s8cYyjE4bf4g=
-----END PRIVATE KEY-----
      Paste it into the Private key field in the AoC UI.
      Important: Replace the "\n" characters in the content you pasted with actual line breaks.
    4. In the GCP console, copy the email address of the service account (for example, "ats-google-bucket_name-access@test-project-1234.iam.gserviceaccount.com") and paste it into the Client ID field in the AoC UI.
    5. In the AoC UI, enter the Path that Aspera can access with the format "bucket_name/path". To allow access to the entire bucket, enter the bucket name.
    IBM Cloud Prerequisite: You must have HMAC credentials for the IBM Cloud bucket. Specifically, you need the IBM Cloud bucket Access Key ID and Secret Access Key to complete this procedure.
    1. Enter the region for the bucket.
    2. Enter the bucket Access Key ID.
    3. Enter the bucket Secret Access key.
    4. Enter the name assigned to this bucket.
    5. Enter the path: / or the desired path.
  7. Click Save.

    If you see the error message, "Unable to create ATS access key and secret", see Creating a New Access Key for a troubleshooting procedure.

  8. Download or copy and save the Aspera on Cloud access key and secret according to local site practice. These credentials allow you to access this node for content management and configuration activities. If you download, Aspera generates a text file with the default name KeySecret.txt. Aspera recommends that you rename this file to make it easier to track and manage.
    Important: Aspera on Cloud does not store the secret. Once you complete this step, you can no longer retrieve the secret. You must track these credentials according to your own local site security practices.
  9. To protect content on this node with Aspera encryption at rest, do one of the following:
  10. Click Save to complete creation of the new transfer service node.
This storage can now be used to support a workspace.

Rotate Keys for Your Azure Storage

To support key rotation for Azure storage, you can update your attached Azure node with new storage credentials.

To complete this procedure, you need the following:
  • From your Azure storage, the new storage credentials applicable after key rotation.
  • The Aspera node name and Aspera secret for your Azure storage attached to Aspera on Cloud.
To update your Azure storage credentials, do the following:
  1. In your Azure storage management portal, update the credentials for the storage attached to Aspera on Cloud. Capture the new credentials to apply in Aspera on Cloud.
  2. In Aspera on Cloud, go to Nodes and storage > Nodes; click the row of your Azure node. Enter the Aspera node key and secret.
  3. Click Update storage credentials.
  4. In the modal that appears, enter the new credentials from your Azure storage.
  5. Click Save.

Result: You have updated the storage credentials for your Azure node in your Aspera on Cloud organization. The Aspera on Cloud node access key and secret remain unchanged.