Microsoft Azure Blob Storage

Hot, cool, and cold tier blob storage is supported. Refer to Microsoft Azure documentation for the differences between these storage types.

Note

If you want to use Workload Identity Federation to access the storage for a portal in AWS, you must first set it up in Microsoft Entra ID. For details, see Authenticating Microsoft Azure Blob Storage for an AWS-Hosted Portal

Container Name – The name of a Microsoft Azure blob container.
Storage Account Name – The Microsoft Azure account name.
Use one of the following options:

Use Secret Access Key
- Secret Access Key – The Microsoft Azure access key.
Use Managed Identity for Azure-hosted portals, to assign Azure roles to the portal identity instead of storing access keys in CTERA as part of zero-trust and cloud security programs.
- Client Id (Optional) – The Microsoft Azure client ID. If this is not entered the system ID is used.
Use Workload Identity Federation For AWS-hosted portals so that no Azure credentials are required. It uses AWS IAM identity to authenticate to Microsoft Azure Blob Storage without storing any Azure secrets. The portal AWS EC2 instance uses the IAM role to mint a short-lived JWT, which Azure Entra ID trusts via a federated credential. This method is fully keyless.
- Tenant Id – The Directory (tenant) ID from the Entra ID registered application.
- Client Id – The Application (client) ID from the Entra ID registered application.
- IAM Role ARN – The AWS ARN value for the portal.

Endpoint – The endpoint of the service. The default value is core.windows.net except for China Azure where the endpoint should be core.chinacloudapi.cn. Normally, this value should not be changed. The port for the endpoint can be customized by adding the port after the URL, using a colon (:) separator. The default port is 80.
Use HTTPS – Use HTTPS to connect with the storage node. If this option is not selected, HTTP will be used instead.

Note

Enabling HTTPS reduces performance.

Direct Mode – Data is uploaded and downloaded directly to and from the storage node and not via the portal. If direct mode is defined for the storage node, CTERA recommends setting the deduplication method to fixed blocks and keeping the default 4MB fixed block size. For details, see Default Settings for New Folder Groups.

Note

Once Direct Mode is set, the Use HTTPS option is also checked and cannot be unchecked.

Using Tiering For CTERA Portal Storage

Each object in Azure Blob Storage has an access tier associated with it. The following tiers are supported:
Hot – Optimized for storing data that is accessed frequently.
Cool – Optimized for storing data that is infrequently accessed and stored for at least 30 days.
Cold – Optimized for storing data that is rarely accessed but still requires immediate availability when needed.

CTERA Portal Azure Blob Storage can use both hot, cool, and cold tiers. Data in the cool access tier can tolerate slightly lower availability, but still requires high durability, retrieval latency, and throughput characteristics similar to hot data. For cool and cold data, a lower availability service-level agreement (SLA) and higher access costs compared to hot data are acceptable trade-offs for lower storage costs. You configure your Azure Blob Storage bucket to tier data that is not frequently accessed in the cool tier with Azure Blob Storage lifecycle management to create a rule-based policy to transition your data to the best access tier. For more details, see https://azure.microsoft.com/en-us/blog/azure-blob-storage-lifecycle-management-now-generally-available/.

For example, the following sample policy manages the lifecycle for such data. It applies to block blobs in container portalsn and tiers tier blobs to cool storage 7 days after the last modification.

{
    "rules": [
    {
	"name": "rulePortalsn",
	"enabled": true,
	"type": "Lifecycle",
	"definition": {
		"filters": {
			"blobTypes": [ "blockBlob" ],
			"prefixMatch": [ "portalsn" ]
		},
		"actions": {
			"baseBlob": {
				"tierToCool": { "daysAfterModificationGreaterThan": 7 },
			}
        	}
	}
    }
    ]
}

Authenticating Microsoft Azure Blob Storage for an AWS-Hosted Portal

CTERA Portal supports Workload Identity Federation (WIF) to allow AWS-hosted Portals to authenticate to Microsoft Azure Blob Storage without storing any Azure secrets. The portal AWS EC2 instance uses the IAM role to mint a short-lived JSON Web Token (JWT), which Azure Entra ID trusts via a federated credential, making the authentication fully keyless.

Each server in the portal cluster must be an AWS EC2 instance with the same IAM role, that includes the "sts:GetWebIdentityToken" action.

To create the authentication:

In AWS, go to the EC2 console and click Instances in the navigation pane.
Select the portal instance and click the Security tab.
Click the IAM role under Security details.
The Identity and Access Management (IAM) page is displayed with the Roles option under Access Management for that IAM role with the Permission policies listed.
Note the ARN value in the Summary for later use.

Edit the IAM that you used when installing the portal in AWS by adding the following action: `"sts:GetWebIdentityToken"
For example, using the IAM from Creating the IAM, Policy and Role for the Portal :

{"Version": "2012-10-17",
      "Statement": [{
        "Effect": "Allow",
        "Action": [
            "ec2:AttachVolume",
            "ec2:DescribeVolumes",
            "ec2:DetachVolume",
            "ec2:CreateSnapshot",
            "ec2:DeleteSnapshot",
            "ec2:DescribeSnapshots",
            "s3:CreateBucket",
            "s3:GetBucketObjectLockConfiguration"
            "s3:ListBucket",
            "s3:GetObject",
            "s3:PutObject",
            "s3:PutObjectRetention",
            "s3:DeleteObject",
            "s3:GetBucketLocation",
            "s3:ListAllMyBuckets"
            "cloudwatch:GetMetricStatistics",
            "cloudwatch:ListMetrics",
            "cloudwatch:GetMetricData"
            "sts:GetWebIdentityToken"
        ],
        "Resource": [
            "*"
        ]
    }]
}

Select Account settings under Access Management and make sure that the status for Outbound Identify Federation is enabled.
When Outbound Identify Federation is enabled, the Token Issuer URL is displayed.
Note the Token Issuer URL value for later use.
Login to Azure as the administrator.
The home page is displayed.
Access the Microsoft Entra ID service.
The Overview page is displayed.
Click Add > App registration.
Enter a name for the application and click Register.

The application page, with the name you specified is displayed.
Note the Application (client) ID and Directory (tenant) ID values.
Click Manage > Certificates & secrets in the navigation pane.
Click Federated credentials (0).
Click Add credential.
Select Other issuer from the drop-down list.
Enter the following:
Issuer – The Token Issuer URL value you noted earlier from AWS, when Outbound Identify Federation is enabled.
Type – Select Explicit subject identifier.
Value – The ARN value you noted earlier from AWS.
Name – A name to identify the credentials.
Audience – Enter api://AzureADTokenExchange
Click Add.
Access the Storage Accounts service.
Under the Resources tab access your account.
Click Access Control (IAM) in the account navigation pane.
Click Add > Add role assignment.
Select the Storage Blob Data Contributor role.
The Add role assignment page is displayed.
For Assign access to select User, group or service principal.
Click Select members.
The list of members and applications is displayed.
Select the registered application.
Review and assign the role.