ACLs
ACLs (Access Control Lists) define who can access objects and what operations they can perform. They protect stored data by controlling read, write, and delete permissions at the object and bucket level. The following ACL flags are available for AWS CLI (aws s3api put-object-acl or put-bucket-acl) and S3cmd (s3cmd setacl):
Policies
Policies are JSON documents that define access rules at a granular level — specifying which actions a user or all users can perform on objects and buckets. The maximum policy size is 20 KB.The storage owner configures policies. The AWS reference lists all supported S3 actions, conditions, and resource types.
Configure access via ACLs and policies
All commands use AWS CLI and S3cmd interchangeably — choose whichever is already configured on the system. In all commands and JSON files, replace the following placeholders:sample.jpg— the object name.my_bucket— the bucket name.s-ed1.cloud.gcore.lu— the storage hostname from the Details dialog; the service URLs reference lists all location endpoints.
Public object access via ACL
To allow all users to download an object, apply thepublic-read ACL (--acl public-read in AWS CLI or --acl-public in S3cmd).
AWS CLI:
Bucket listing via ACL
To allow all users to list objects in a bucket, apply thepublic-read ACL to the bucket.
AWS CLI:
Public object access via policy
1
Create the policy file
Create a JSON file with the following policy:
2
Apply the policy
Apply the policy to the bucket.AWS CLI:S3cmd:All objects in the bucket become publicly accessible for download.
This policy grants direct file access but does not allow listing the files in the bucket.
Directory access denial via policy
1
Create the policy file
Create a JSON file that allows public read on the bucket but denies access to the
secret/ directory:2
Apply the policy
Apply the policy to the bucket.AWS CLI:S3cmd:
IP-based access via policy
A bucket policy can also limit anonymous access by source IP address or CIDR range. Use a positive Allow statement with anIpAddress condition, because Deny with NotIpAddress does not restrict traffic on Gcore Object Storage.
These conditions apply to anonymous requests, while authenticated owner credentials retain their normal permissions.
Replace the example IP addresses with the source IPs that should be allowed. The condition matches the client address seen by Object Storage for virtual-hosted and path-style requests, so a client-supplied X-Forwarded-For header cannot bypass the restriction.
1
Create the policy file
Create a JSON file using one of the following patterns.Grant every S3 operation from one IPv4 address:To allow the same operations from two IPv4 addresses, list both in Grant the same operations from two CIDR networks:Allow anonymous object downloads from one IPv4 address, while ListBucket and writes remain denied:
aws:SourceIp:2
Apply the policy
Apply the policy to the bucket.AWS CLI:S3cmd:Requests from an allowed source return HTTP 200, while requests from any other source return HTTP 403.
Referrer-based access via policy
1
Create the policy file
Create a JSON file that restricts access to requests originating from specific websites. Replace
http://www.example.com/ and http://example.com/ with the actual URLs:2
Apply the policy
Apply the policy to the bucket.AWS CLI:S3cmd:
User access grant via policy
1
Create the policy file
Create a JSON file that grants a specific user read and list access. Replace
1234-test with the storage username from the Details dialog:2
Apply the policy
Apply the policy to the bucket.AWS CLI:S3cmd: