Use a private bucket as an origin

Private S3-compatible buckets — from Amazon or CDB — can be used as a CDN resource origin. CDN servers authenticate with each bucket using AWS Signature V4, which requires an Access Key ID, Secret Access Key, Hostname, and Region. Origin groups support multiple origins with individual authentication settings per origin, and an optional Host header override per origin.

Authentication data

The required authentication data is available in the S3 storage account.

All essential keys are in the Managing access keys guide from Amazon.

The Hostname and Region are in the Details section under the Storages tab.

Caution

We don't store the Access Key ID and Secret access key for S3 storage. Save them after creating the storage. To regenerate them, click Generate new keys in the Details section.

Configure a private bucket as an origin

An origin group can be configured either during CDN resource creation or in advance from the Origin groups tab. The steps below cover CDN resource creation. When creating a group from the Origin groups tab directly, the process is the same starting from step 2.

1. Go to the CDN resource creation page and select the Specify content origin option in the Origin section.

2. Click Add origin to add an origin to the group. For each origin added, configure the following:

a. Select the S3 storage tab.

b. Select the type of S3 storage: Amazon or Other.

c. Specify the authentication data for the selected storage type:

• For Amazon: Access Key ID, Secret access key, and AWS region
• For Other: Hostname (including the bucket prefix), Access Key ID, Secret access key, and Region

💡

Tip

To determine the region of a CDB Object Storage bucket, use the S3 service URLs and default region names guide.

d. Enter the Bucket name. CDN servers use this value only when calculating the AWS Signature V4 Authorization header for the private origin. The CDN does not automatically add the value from this field to the request URL sent to the origin.

If the origin requires the bucket name in the request URL, check the S3 or storage provider documentation to determine whether the bucket must be included in the origin hostname or the request path.

• Origin hostname: Include the bucket in the hostname, for example, my-bucket.s3.amazonaws.com or my-bucket.s-ed1.cloud.gcore.lu. No additional CDN configuration is required.
• Path: To keep the bucket name out of end-user URLs, such as https://my.domain.com/content.png, add a Rewrite rule that prepends it to requests sent to the origin. For example, the rule /(.*) /my-bucket/$1 transforms the end-user request into an origin request for /my-bucket/content.png.

e. Optional: enter the storage hostname in the Host header override field for this origin. When left empty, the Host header configured in the resource settings applies to all origins. When set, it overrides the global value for this specific origin — required when multiple origins point to different buckets that each need a unique hostname.

The Host header format depends on the storage provider:

• For CDB Object Storage: {bucket-name}.s-ed1.cloud.gcore.lu
• For most other providers (including Amazon): {bucket-name}.s3.{region-code}.{storage-hostname}

ℹ️

Specifying the bucket in the Host header restricts CDN access to that bucket only, preventing unintended access to other data in the storage account.

In the example below, the origin group uses a private bucket test-private in CDB Object Storage with the endpoint s-ed1.cloud.gcore.lu:

3. To add more origins to the group, click + Add origin again and repeat step 2 for each one. Each origin can have different credentials and a separate Host header override.

4. Continue the CDN resource creation according to the Create CDN resource for static assets only guide.

5. If the per-origin Host header override is not used, go to the resource settings and open the Host header option in the HTTP headers section. Enter the storage hostname in the format shown in step 2e above, then click Save changes.

An API token is required. Send a POST request to the origin groups endpoint with the authentication credentials for each origin.

Method	POST
Header	Bearer {{access_token}} application/json
Payload	{ "name": "YourOriginGroup", "useNext": true, "auth_type": "awsSignatureV4", "auth": { "s3_type": "amazon", "s3_access_key_id": "EXAMPLEFODNN7EXAMPLE", "s3_secret_access_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY", "s3_bucket_name": "bucket_name", "s3_region": "us-east-2" } }
Request parameter	See the API documentation for the full parameter list.
Response	201 Successful 400 Request for creation origin group is failed 403 Group creation is forbidden

A REST tool such as cURL or Postman can be used to send requests.

1. In Postman, open a new request tab.

a. Set the request method to POST.

b. Enter the API URL in the request URL field.

2. Go to the Auth tab.

a. Select Bearer Token from the Type dropdown.

b. Paste the generated access token into the Token field.

3. Go to the Body tab.

a. Select raw as the data type.

b. Select JSON from the format dropdown.

c. Enter the payload in the text area, replacing the sample values with actual credentials.

4. Click Send.

Troubleshooting Amazon S3 (403 Forbidden for HEAD requests)

Private Amazon S3 buckets used as an origin can return a 403 Forbidden error for HEAD requests while GET requests succeed with 200 OK. This discrepancy typically has one of four causes:

1. Restricted object-level permissions: The bucket or IAM policy permits public read access, but the object's Access Control List (ACL) denies access to the IAM user or role — AWS S3 returns 403 for HEAD in this case.

2. Different policies in effect: The IAM identity making the HEAD request lacks s3:GetObjectAttributes or equivalent metadata-read permissions, causing AWS S3 to return 403 for HEAD while GET succeeds under a broader policy.

3. Incorrect parameters in presigned URLs: A presigned URL generated with mismatched parameters (access key, secret access key, bucket name, or object key) causes AWS to return 403. The parameters must be consistent for both HEAD and GET requests.

4. Different owners for bucket and object: When the bucket and object belong to different AWS accounts and the object owner hasn't granted the necessary permissions to the bucket owner, AWS returns 403 for HEAD and 200 for GET.

To resolve the issue, modify the bucket policy, IAM permissions, or the object's ACL as required.