Use a private bucket as an origin

​

Authentication data

• Amazon AWS
• Gcore

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.

​

Configure a private bucket as an origin

• Customer Portal
• API

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

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

d. Enter the Bucket name.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 Gcore 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 Gcore 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)

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.