Object Storage - Bucket ACL – Support Guides

By default, all resources (buckets, objects) and sub-resources (lifecycle configuration, website configuration, etc.) are private in Object Storage. Only the resource owner, i.e., the user account that creates it, has full control.

Access to private resources can be granted via access policies.

Access policies can be categorized broadly into two types:

user-based
resource-based: bucket policies and ACLs are policies that are attached directly to specific resources

User-based

Access policies attached to a specific user are called user policies. A user policy is evaluated using Object Storage IAM permissions and applies only to the specific user attached to it.

Resource-based

ACL

An ACL is a list of permissions granted to identified grantees. ACLs are typically used to grant basic read/write permissions to other accounts.

ACLs can either be attached at the bucket level or the individual object level.

Although ACLs are the legacy way to manage permissions, they are still relevant and not deprecated. However, based on the situation, you might want to use policies to apply fine-grained control of your resources.

Bucket policy

Akin to user policies, a bucket policy controls permissions for a bucket and the objects in it. The difference is that whereas user policies control permissions for a specific user to a list of resources, a bucket policy controls permissions to a specific bucket and its objects for a list of users.

NOTE: Bucket policies are a feature that is not yet available for Object Storage.

Manage permissions with ACLs

Supported grantees

OVHCloud Object Storage supports two types of grantees:

Public Cloud account users
Predefined groups

Public Cloud account

Public Cloud account users are identified by a canonical user ID. When you grant access rights, the canonical user ID is specified by id=<value> where <value> equals <project_name>:<user_name>.

Example: if you have a Public Cloud project named my_project and you have created a user named storage-user then you get id=my_project:storage-user.

Predefined groups

Supported predefined user groups are the following and are identified by a URI:

log delivery group: this group contains the applicative users used by OVHcloud services to write server access logs inside buckets (read our Server access logging guide for more information)

http://acs.amazonaws.com/groups/s3/LogDelivery

authenticated users group: this group contains all the OVHcloud Public Cloud account users

http://acs.amazonaws.com/groups/global/AuthenticatedUsers

all users group: this group is the default group that contains all users in the world and is equivalent to anonymous users

http://acs.amazonaws.com/groups/global/AllUsers

Permissions

The managed permissions are listed below. Note that depending on the level (bucket or object), not all permissions can apply.

Permission	Bucket level	Object level
READ	allows to list all objects in the bucket	allows to read an object and its metadata
WRITE	allows creation/deletion/overwrites of objects in the bucket	n/a
READ_ACP	allows read of the bucket ACL	allows read of the object ACL
WRITE_ACP	allows creation/deletion/overwrites of the bucket ACL	allows creation/deletion/overwrites of the object ACL
FULL_CONTROL	shorthand for READ, WRITE, READ_ACP, WRITE_ACP on the bucket	shorthand for READ, READ_ACP, WRITE_ACP on the object

Predefined ACLs

Predefined ACLs have a predefined set of grantees and permissions and are a convenient shorthand for the most common use cases.

ACL	Description	Bucket	Object	Comment
private	default behavior, owner has FULL_CONTROL	x	x
public-read	owner has FULL_CONTROL AllUsers group has READ	x	x
public-read-write	owner has FULL_CONTROL AllUsers group has READ, WRITE	x	x
authenticated-read	owner has FULL_CONTROL AuthenticatedUsers group has READ	x	x
bucket-owner-read	object owner has FULL_CONTROL bucket owner has READ		x	currently not managed yet
bucket-owner-full-control	object owner and bucket owner both have FULL_CONTROL		x	currently not managed yet
log-delivery-write	LogDelivery group has WRITE, READ_ACP	x

Instructions

Set ACL on a bucket

You can set the ACL on a bucket at its creation or afterward, by calling the put-bucket-acl endpoint.

Example:

$ aws s3api create-bucket --bucket my-bucket --region us-east-va --acl public-read

In this example, we created a bucket named "my-bucket" using a predefined ACL "public-read".

To verify that ACLs are set correctly, you can use the following command to return the ACL:

$ aws s3api get-bucket-acl --bucket my-bucket

{
    "Owner": {
        "DisplayName": "2171889990277389:user-xxxxxxxxxxxx",
        "ID": "2171889990277389:user-xxxxxxxxxxxx"
    },
    "Grants": [
        {
            "Grantee": {
                "Type": "Group",
                "URI": "http://acs.amazonaws.com/groups/global/AllUsers"
            },
            "Permission": "READ"
        },
        {
            "Grantee": {
                "DisplayName": "2171889990277389:user-xxxxxxxxxxxx",
                "ID": "2171889990277389:user-xxxxxxxxxxxx",
                "Type": "CanonicalUser"
            },
            "Permission": "FULL_CONTROL"
        }
    ]
}

To change the ACL, you can call the put-bucket-acl endpoint by using the AWS CLI:

$ aws s3api put-bucket-acl --bucket acl-bucket --grant-write id=po-training:user-yyyyyyyyyy

Here, we change the ACL to give the account user "user-yyyyyyyyyy" the permission to write in the bucket.

Again, to verify that ACLs are set correctly:

$ aws s3api get-bucket-acl --bucket my-bucket

{
    "Owner": {
        "DisplayName": "2171889990277389:user-xxxxxxxxxxxx",
        "ID": "2171889990277389:user-xxxxxxxxxxxx"
    },
    "Grants": [
        {
            "Grantee": {
                "DisplayName": "po-training:user-yyyyyyyyyy",
                "ID": "po-training:user-yyyyyyyyyy",
                "Type": "CanonicalUser"
            },
            "Permission": "WRITE"
        }
    ]
}

Set ACL on an object

Similar to bucket level, you can set the ACL on an object at its creation or afterward.

Example:

$ aws s3api put-object --bucket my-bucket --body file.txt --key file --grant-full-control id=po-training:user-yyyyyyyyyy

In this example, we created an object named "file" and we gave "FULL_CONTROL" on that object to account user "user-yyyyyyyyyy".

To verify that ACLs are set correctly, you can use the following command to return the ACL:

$ aws s3api get-object-acl --bucket my-bucket --key file

{
    "Owner": {
        "DisplayName": "2171889990277389:user-xxxxxxxxxxxx",
        "ID": "2171889990277389:user-xxxxxxxxxxxx"
    },
    "Grants": [
        {
            "Grantee": {
                "DisplayName": "2171889990277389:user-xxxxxxxxxxxx",
                "ID": "2171889990277389:user-xxxxxxxxxxxx",
                "Type": "CanonicalUser"
            },
            "Permission": "FULL_CONTROL"
        },
        {
            "Grantee": {
                "DisplayName": "po-training:user-yyyyyyyyyy",
                "ID": "po-training:user-yyyyyyyyyy",
                "Type": "CanonicalUser"
            },
            "Permission": "FULL_CONTROL"
        },
    ]
}

To change the ACL, you can call the put-object-acl endpoint by using the AWS CLI:

$ aws s3api put-object-acl --bucket acl-bucket --grant-read id=po-training:user-yyyyyyyyyy

Here, we changed our mind and decided to only give the account user "user-yyyyyyyyyy" the permission to read in the bucket instead of full control.

Again, to verify that ACLs are set correctly, use the following command:

$ aws s3api get-object-acl --bucket my-bucket --key file

{
    "Owner": {
        "DisplayName": "2171889990277389:user-xxxxxxxxxxxx",
        "ID": "2171889990277389:user-xxxxxxxxxxxx"
    },
    "Grants": [
        {
            "Grantee": {
                "DisplayName": "2171889990277389:user-xxxxxxxxxxxx",
                "ID": "2171889990277389:user-xxxxxxxxxxxx",
                "Type": "CanonicalUser"
            },
            "Permission": "FULL_CONTROL"
        },
        {
            "Grantee": {
                "DisplayName": "po-training:user-yyyyyyyyyy",
                "ID": "po-training:user-yyyyyyyyyy",
                "Type": "CanonicalUser"
            },
            "Permission": "READ"
        },
    ]
}

Best practices

When to use ACLs?

At object level

As mentioned before, ACLs can be attached at the object level.

You might consider the following scenarios to use object ACL.

the bucket owner and the object owner are not the same: in a scenario where the bucket owner has granted another account to write objects inside the bucket, access to those objects must be granted through ACLs
permissions vary from individual object to individual object

At bucket level

We strongly advise you to use policies instead for better and more fine-grained access control over the bucket and its objects. However, for very basic permission control needs, you might consider using bucket ACLs to grant permissions to the objects and ACLs related to the bucket.

When to use bucket policies?

You might consider using bucket policies if you want to set cross-account permissions over the resources related to a specific bucket.

When to use user policy?

You might consider using user policies if you want to set cross-resource permissions for a specific account.

Important!

ACLs and policies can be combined. However, the principle of least privilege will always be applied and can be summarized as "allow only if there is an explicit allow and no explicit deny, else, deny all."

Go further

For more information and tutorials, please see our other Object Storage support guides or explore the guides for other OVHcloud products and services.

If you need training or technical assistance to implement our solutions, contact your sales representative or click on this link to get a quote and ask our Professional Services experts for a custom analysis of your project.

*S3 is a trademark filed by Amazon Technologies, Inc. OVHcloud's service is not sponsored by, endorsed by, or otherwise affiliated with Amazon Technologies, Inc.