There are three ways to control access to Google Cloud Storage buckets and objects:
- Access Control Lists (ACLs), which provide a way to specify read or write access for specified Google accounts and groups.
- Signed URLs (Query String Authentication), which provide a way to give time-limited read or write access to anyone in possession of the URL, regardless of whether they have a Google account,
- Signed Policy Documents, which provide a way to specify what can be uploaded to a bucket. Policy documents allow greater control over size, content type, and other upload characteristics than signed URLs, and can be used by website owners to allow visitors to upload files to Google Cloud Storage.
These are not mutually exclusive. You can use ACLs to protect buckets and objects, while at the same time using signed URLs or policy documents so that can access those resources, bypassing the ACL mechanism.
This document shows you how to configure access control using the Google Developers Console, gsutil, and the XML and JSON APIs. The Developers Console and gsutil are easiest to use if you are new to access control. If you are specifying ACLs using an API, you should have experience making HTTP requests. You can use your favorite tool or application to send the HTTP requests. In the examples, we use the cURL tool. You can get authorization tokens to use in the cURL examples from the OAuth 2.0 Playground.
For examples of sharing and collaboration scenarios that involve setting bucket and object ACLs, see Sharing and Collaboration.
Contents
- About access control lists
- Permissions and scopes
- Bucket and object ACLs
- Default bucket and object ACLs
- Managing access control
- Signed URLs (query string authentication)
About Access Control Lists
Google Cloud Storage uses access control lists (ACLs) to manage bucket and object access. ACLs are the mechanism you use to share objects with other users and allow other users to access your buckets and objects.
An ACL consists of one or more entries, where each entry grants permissions to a scope. Permissions define the actions that can be performed against a bucket or object (for example, read or write); the scope defines who the permission applies to (for example, a specific user or group of users). Scopes are sometimes referred to as grantees. The maximum number of ACL entries you can create for a bucket or object is 100. When the ACL scope is a group or domain, it counts as one ACL entry regardless of how many users are in the group or domain.
When a user requests access to a bucket or object, the Google Cloud Storage system reads
the bucket or object ACL and determines whether to allow or reject the access request. If the ACL
grants the user permission for the requested operation, the request is allowed. If the ACL does not
grant the user permission for the requested operation, the request fails and a 403
Forbidden error (Access Denied) is returned.
Permissions and scopes
Permissions
Google Cloud Storage lets you assign the following concentric permissions for your buckets and objects as shown in the following table:
READER |
WRITER |
OWNER |
Default | |
|---|---|---|---|---|
| Objects | Lets a user download an object's data. | You cannot apply this permission to objects. | Gives a user READER access. It also lets a user read and write object
metadata, including ACLs. |
Objects have the predefined project-private ACL applied when they are uploaded. Objects are always owned by the original requester who uploaded the object. |
| Buckets | Lets a user list a bucket's contents.1 | Lets a user list, create, overwrite, and delete objects in a bucket. 2 | Gives a user READER and WRITER permissions on the bucket. It also lets a user read and write bucket metadata, including ACLs. |
Buckets have the predefined project-private ACL applied when they are created. Buckets are always owned by the project-owners group. |
1 The following bucket metadata properties are not returned
with a bucket's resource without OWNER:
acl,
cors,
defaultObjectAcl,
lifecycle,
logging,
owner, and
projectNumber.
2 The following bucket metadata properties cannot be
changed:
acl,
cors,
defaultObjectAcl,
lifecycle,
logging,
versioning and
website.
Note: You cannot grant discrete permissions for reading or writing
ACLs or other metadata. To let someone read and write ACLs you must grant them
OWNER permission.
In this page, we generally refer to the permissions as READER, WRITER,
and OWNER, which are how they are specified in the JSON API and the Google Developers Console.
If you are using the XML API, the equivalent
permissions are READ, WRITE, and FULL_CONTROL, respectively.
And, when you use OAuth 2.0 Authentication to
authenticate tools and applications (grant permission to them) to access Google Cloud Storage API
on your behalf, access is restricted by OAuth scope devstorage.read_only,
devstorage.read_write, and devstorage.full_control. The following table
summarizes the permissions terminology you will commonly encounter:
| JSON API | XML API | OAuth2 URL |
|---|---|---|
READER |
READ |
https://www.googleapis.com/auth/devstorage.read_only |
WRITER |
WRITE |
https://www.googleapis.com/auth/devstorage.read_write |
OWNER |
FULL_CONTROL |
https://www.googleapis.com/auth/devstorage.full_control |
Scopes
An ACL consists of one or more entries, where each entry grants permissions to a scope. You can specify an ACL scope using any of the following entities:
- Google Storage ID
A Google Storage ID is a string of 64 hexadecimal digits that identifies a specific Google account holder or a specific Google group. It is sometimes referred to as a canonical ID. The following is an example of a Google Storage ID:
84fac329bceSAMPLE777d5d22b8SAMPLE77d85ac2SAMPLE2dfcf7c4adf34da46Project teams are identified by a Google Storage ID. The project editors group and project owners group are also identified using Google Cloud Storage IDs. These IDs are unique to a project.
- Google account email address
Every user who has a Google account must have a unique email address associated with that account. You can specify a scope by using any email address that is associated with a Google account, such as a gmail.com address.
Google Cloud Storage remembers email addresses as they are provided in ACLs until the entries are removed or overwritten. If a user changes email addresses, you should update ACL entries to reflect these changes.
- Google group email address
Every Google group has a unique email address that is associated with the group. For example, the Google Cloud Storage Announce has the following email address: gs-announce@googlegroups.com. You can find the email address that is associated with a Google group by clicking About on the homepage of every Google group. For more information about Google groups, see the Google groups homepage.
Like Google account email addresses, Google Cloud Storage remembers group email addresses as they are provided in ACLs until the entries are removed or overwritten. You do not need to worry about updating Google Group email addresses because Google Group email addresses are permanent and unlikely to change.
- Google Apps domain
Google Apps customers can associate their email accounts with an Internet domain name. When you do this, each email account takes the form username@yourdomain.com. You can specify a scope by using any Internet domain name that is associated with a Google Apps account.
- Special identifier for all Google account holders
This special scope identifier represents anyone who is authenticated with a Google account. The special scope identifier for all Google account holders is
allAuthenticatedUsers. - Special identifier for all users
This special scope identifier represents anyone who is on the Internet, with or without a Google account. The special scope identifier for all users is
allUsers.
Usually, you specify scopes using an email address, a domain, or one of the special identifiers. If you want to specify a scope using a Google Storage ID, you can find the Google Storage ID as shown in the following section.
Finding Google Cloud Storage IDs
You can find a user's Google Storage ID by retrieving the ACL of an object
that the user uploaded. An authenticated user must have OWNER permission to read
object metadata, which includes the object ACL.
To find a user's Google Storage ID:
Google Developers Console
- In the Google Developers Console, find an object that the user uploaded.
- Click more actions
at the end of the object row and select Edit permissions
. - In the permissions dialog, find the permission granted to the user, which includes the user's Google Storage ID.
gsutil
- Identify an object that the user uploaded.
- Use the
gsutil aclcommand:gsutil acl get gs://<path-to-object>
- In the response, find the
entityId, which is the user's Google Storage ID.
JSON API
XML API
- Identify an object that the user uploaded.
- Retrieve that object's metadata with a
GET Object request.
curl -X GET -H "Authorization: Bearer <token>" \ http://storage.googleapis.com/<bucket-name>/<object-name>?acl - In the response body, find the
<ID>element in the<OWNER>container.
You can also retrieve Google Cloud Storage IDs for project roles (team, editors, and owners) by either retrieving ACLs on a bucket if the ACLs have not been changed from the default, or by using getting them from the Project dashboard.
To find Google Cloud Storage IDs for project groups:
- Go to the Google Developers Console.
- Select a project by clicking its name.
- In the left sidebar, select Storage > Cloud Storage > Storage access.
- The project IDs are in the Google Cloud Storage IDs section.
Bucket and object ACLs
ACL syntax
The tool or API you use to set and get ACLs determines the ACL syntax you will use. The ACL syntaxes look different, but they contain the same ACL information: entries that grant permissions to scopes.
Google Developers Console
When specifying an ACL in the Google Developers Console, you specify:
- The ACL entry type: Domain, Group, User, or Project.
- The ACL entry entity value.
- For Domain specify a domain, for example "example.com".
- For Group specify the group's email address.
- For User specify the user's email address.
- For Project either specify the Google Storage ID of the project role, Team, Editors, or Owners. See Finding Google Storage IDs.
- The ACL entry permission:
READER,WRITER(bucket only), orOWNER.
The following example shows permissions for a bucket in the Developers Console.

You can grant the allUsers or allAuthenticatedUsers scope access to
a bucket or object using an entry type User.
gsutil
gsutil acl enables you to specify ACLs in a
couple of ways. You can specify:
- Individual grants. For example,
gsutil acl set -u jane@gmail.com:R gs://bucket. - Canned ACLs. For example,
gsutil acl set private gs://bucket. - ACLs in JSON format. For example,
gsutil acl set acl.json gs://bucketwhere acl.json contains ACLs specified in JSON format.
When gsutil returns ACLs for buckets and objects (gsutil acl get), they are in
the same JSON format that you can use to set ACLs. ACLs in JSON format use the JSON API property
names, such as entity and role.
See the JSON API syntax
for more information about how to interpret the output or run gsutil help acls.
The following command returns a bucket's ACL.
gsutil acl get gs://<bucket-name>
The following example shows different bucket ACL entries.
[
{
"entity": "project-owners-123412341234",
"projectTeam": {
"projectNumber": "123412341234",
"team": "owners"
},
"role": "OWNER"
},
{
"entity": "project-editors-123412341234",
"projectTeam": {
"projectNumber": "123412341234",
"team": "editors"
},
"role": "OWNER"
},
{
"entity": "project-viewers-123412341234",
"projectTeam": {
"projectNumber": "123412341234",
"team": "viewers"
},
"role": "READER"
},
{
"email": "gs-announce@googlegroups.com",
"entity": "group-gs-announce@googlegroups.com",
"role": "READER"
},
{
"email": "jane@gmail.com",
"entity": "user-jane@gmail.com",
"role": "READER"
},
{
"entity": "allUsers",
"role": "READER"
},
{
"entity": "allAuthenticatedUsers",
"role": "READER"
}
]
JSON API
In the JSON API, ACLs are in JSON format. You must attach JSON to the body of requests to change bucket and object ACLs. JSON is returned when you get bucket and object ACLs.
For definitions of the bucket and object ACL properties, see the BucketAccessControls and ObjectAccessControls resources, respectively.
The following example shows different bucket ACL entries.
"acl": [
{
"kind": "storage#bucketAccessControl",
"id": "example-bucket/project-owners-123412341234",
"selfLink": "https://www.googleapis.com/storage/v1/b/example-bucket/acl/project-owners-123412341234",
"bucket": "example-bucket",
"entity": "project-owners-123412341234",
"role": "OWNER",
"projectTeam": {
"projectNumber": "123412341234",
"team": "owners"
},
"etag": "CDk="
},
{
"kind": "storage#bucketAccessControl",
"id": "example-bucket/project-editors-123412341234",
"selfLink": "https://www.googleapis.com/storage/v1/b/example-bucket/acl/project-editors-123412341234",
"bucket": "example-bucket",
"entity": "project-editors-123412341234",
"role": "OWNER",
"projectTeam": {
"projectNumber": "123412341234",
"team": "editors"
},
"etag": "CDk="
},
{
"kind": "storage#bucketAccessControl",
"id": "example-bucket/project-viewers-123412341234",
"selfLink": "https://www.googleapis.com/storage/v1/b/example-bucket/acl/project-viewers-123412341234",
"bucket": "example-bucket",
"entity": "project-viewers-123412341234",
"role": "READER",
"projectTeam": {
"projectNumber": "123412341234",
"team": "viewers"
},
"etag": "CDk="
},
{
"kind": "storage#bucketAccessControl",
"id": "example-bucket/group-gs-announce@googlegroups.com",
"selfLink": "https://www.googleapis.com/storage/v1/b/example-bucket/acl/group-gs-announce@googlegroups.com",
"bucket": "example-bucket",
"entity": "group-gs-announce@googlegroups.com",
"role": "READER",
"email": "gs-announce@googlegroups.com",
"etag": "CDk="
},
{
"kind": "storage#bucketAccessControl",
"id": "example-bucket/user-jane@gmail.com",
"selfLink": "https://www.googleapis.com/storage/v1/b/example-bucket/acl/user-jane@gmail.com",
"bucket": "example-bucket",
"entity": "user-jane@gmail.com",
"role": "READER",
"email": "jane@gmail.com",
"etag": "CDk="
},
{
"kind": "storage#bucketAccessControl",
"id": "example-bucket/allUsers",
"selfLink": "https://www.googleapis.com/storage/v1/b/example-bucket/acl/allUsers",
"bucket": "example-bucket",
"entity": "allUsers",
"role": "READER",
"etag": "CDk="
},
{
"kind": "storage#bucketAccessControl",
"id": "example-bucket/allAuthenticatedUsers",
"selfLink": "https://www.googleapis.com/storage/v1/b/example-bucket/acl/allAuthenticatedUsers",
"bucket": "example-bucket",
"entity": "allAuthenticatedUsers",
"role": "READER",
"etag": "CDk="
}
]
XML API
In the XML API, you work with ACLs in XML format. You must attach an XML document to the body of requests to change bucket and object ACLs. An XML document is returned when you get bucket and object ACLs. The XML document contains the individual bucket or object ACL entries.
The following table provides an overview of the XML API ACL syntax. The RELAX NG Compact Syntax Format Schema describes the exact formatting requirements of the Google ACL XML.
| Element | Description |
|---|---|
AccessControlList |
Container for Entries and Owner elements. |
Owner |
Container for DisplayName and ID elements. This element is
not required for objects since an object is always owned by the user who uploaded it. This element
is used when you are using Amazon S3 ACL syntax in a migration
scenario.
Amazon S3 is a trademark of Amazon.com, Inc. or its affiliates
in the United States and/or other countries.
|
Entries |
Container for zero or more Entry elements. |
Entry |
Container for Scope and Permission elements. An Entry
must contain only one Scope and one Permission element. |
Scope |
Container for an ID element that defines the ACL scope. Attribute
type can be UserByID, UserByEmail, GroupByID,
GroupByEmail, GroupByDomain,
AllUsers, or AllAuthenticatedUsers. |
ID |
An identifier for the grantee when the permission entry is specified by ID. |
EmailAddress |
The email identifier for the grantee when the permission entry is specified by email. |
Domain |
The domain identifier for the grantee when the permission entry is specified by domain. |
Permission |
The permission granted READ, WRITE, or FULL_CONTROL. |
Name |
Optional element that can be specified or that may be automatically added if the scope is
UserByEmail or GroupByEmail.
|
Some things to note when working with ACLs using the XML API:
- Only Google ACL XML is accepted.
- Duplicate scopes are not allowed.
You can have many entries in your ACL XML, but you cannot have entries with duplicate scopes. For example, you cannot have two entries with the same scope element of jane@example.com.
The following example shows different bucket ACL entries.
<?xml version="1.0" encoding="UTF-8"?>
<AccessControlList>
<Owner>
<ID>00b4903a9721...</ID>
</Owner>
<Entries>
<Entry>
<Scope type="GroupById">
<ID>00b4903a9722...</ID>
</Scope>
<Permission>FULL_CONTROL</Permission>
</Entry>
<Entry>
<Scope type="GroupById">
<ID>00b4903a9723...</ID>
</Scope>
<Permission>FULL_CONTROL</Permission>
</Entry>
<Entry>
<Scope type="GroupById">
<ID>00b4903a9724...</ID>
</Scope>
<Permission>READ</Permission>
</Entry>
<Entry>
<Scope type="GroupByDomain">
<Domain>example.com</Domain>
</Scope>
<Permission>READ</Permission>
</Entry>
<Entry>
<Scope type="GroupByEmail">
<EmailAddress>gs-announce@googlegroups.com</EmailAddress>
</Scope>
<Permission>READ</Permission>
</Entry>
<Entry>
<Scope type="UserByEmail">
<EmailAddress>jane@gmail.com</EmailAddress>
<Name>jane</Name>
</Scope>
<Permission>READ</Permission>
</Entry>
<Entry>
<Scope type="AllUsers"/>
<Permission>READ</Permission>
</Entry>
<Entry>
<Scope type="AllAuthenticatedUsers"/>
<Permission>READ</Permission>
</Entry>
</Entries>
</AccessControlList>
The Name element in ACL XML
When you retrieve an ACL from a bucket or object, you might notice an additional
<Name> element appended to some of your entries. For example, you might see an
entry that looks like the following:
<Entry>
<Scope type="UserByEmail">
<EmailAddress>jane@gmail.com</EmailAddress>
<Name>Jane</Name>
</Scope>
<Permission>FULL_CONTROL</Permission>
</Entry>
These optional <Name> elements are populated in one of two ways:
- It was provided with the bucket or object's ACLs
When you set ACLs, you may choose to include the
<Name>element with your ACL entries. You can provide any value in the<Name>element and Google Cloud Storage remembers these values until the ACL is removed or overwritten. This can be useful if you are using identifiers that aren't easily identifiable, like Google Cloud Storage IDs. - A
UserByEmailorGroupByEmailscope was used with a public Google profileIf you used either of these scopes but did not provide a
<Name>element, Google Cloud Storage checks if the user or Google Group of the email address has a public Google profile with a public name. If so, Google Cloud Storage populates the<Name>element automatically with the public name.
How to specify ACLs
The following list is an overview of how you can specify ACLs on buckets and objects. The list does not cover how ACLs are specified when you are using a client library to access Google Cloud Storage, however, the information below can be used for guidance.
- Specifying ACLs on buckets
-
Google Developers Console
New buckets are added as project private. Edit the bucket permissions to change the bucket ACL.gsutil
New buckets are added as project private. Usegsutil acl setorgsutil acl chto change the ACL on an existing bucket. For more information, rungsutil help acls.JSON API
XML API
New buckets are added as project private. After creating a bucket with a PUT Bucket request, you can use a second PUT Bucket request with the?aclparameter to change bucket ACL. - Specifying ACLs on objects
-
Google Developers Console
An uploaded object gets the bucket default object ACL. The uploader is added as owner to the ACL. Edit the object permissions to change the object ACL.gsutil
New objects are added with the bucket default object ACL. When copying in the cloud, you can override this behavior with the-poption. You can change the ACL list of an existing object withgsutil acl setorgsutil acl ch.JSON API
Specify theacl[]property in the request body or thepredefinedAclquery parameter in an insert request. If no ACL is specified in the object create request, the object gets the bucket default object ACL. Edit an existing object ACL using theacl[]property or thepredefinedAclquery parameter in a patch or update request.XML API
New objects are added with the bucket default object ACL. After uploading the object with a PUT Object request, you can change ACL with another PUT request using the?aclparameter or thex-googl-aclrequest header. - Specifying default object ACLs
-
Every bucket has a default object ACL that is applied to all objects uploaded to that bucket that do not have a predefined ACL or ACL (JSON API only) specified in the request. Default object ACLs are discussed in the section Default object ACLs.
- Specifying predefined ACLs
-
Predefined (canned) ACLs can also be used to change bucket and object ACLs. A predefined ACL is an alias for a set of ACL entries that can be used to quickly configure access to resources. For more information, see Applying a predefined ACL.
ACL examples
The following examples change the ACL of an existing object.
Google Developers Console
In the Google Developers Console, find the object and edit its permissions.
The following example shows granting jane@gmail.com OWNER permission and the
members of the gs-announce group READER permission on the object
paris.jpg.

gsutil
The following gsutil acl set command uses ACLs from the file
acls.txt and applies them to an
object named paris.jpg.
gsutil acl set acl.txt gs://travel-maps/paris.jpg
acl.txt is shown below and grants jane@gmail.com OWNER permission and the
members of the gs-announce group READER permission on the object
paris.jpg.
[
{
"entity": "user-84fac329bceSAMPLE777d5d22b8SAMPLE77d85ac2SAMPLE2dfcf7c4adf34da46",
"entityId": "84fac329bceSAMPLE777d5d22b8SAMPLE77d85ac2SAMPLE2dfcf7c4adf34da46",
"role": "OWNER"
},
{
"entity": "user-jane@gmail.com",
"email": "jane@gmail.com",
"role": "OWNER"
},
{
"entity": "group-gs-announce@googlegroups.com",
"email": "gs-announce@googlegroups.com",
"role": "READER"
}
]
You can also set the same ACL for this object with individual grants. For example, to grant
jane@gmail.com READER access you can use
gsutil acl ch -u jane@gmail.com:READ gs://travel-maps/paris.jpg.
JSON API
The following cURL command applies a JSON payload from the document acls.json to an object named paris.jpg:
curl -X PATCH --data @acls.json -H "Content-Type: application/json" \
-H "Authorization: Bearer <token>" \
https://www.googleapis.com/storage/v1/b/travel-maps/o/paris.jpg
This is a patch
request with a JSON body (in this case,
acls.json). The request changes the ACL of an object named paris.jpg that is in a bucket named
travel-maps. The ACL grants jane@gmail.com OWNER permission and it grants the
members of the gs-announce group READER permission on the object paris.jpg.
The details of the request are:
PATCH /storage/v1/b/travel-maps/o/paris.jpg HTTP/1.1
Host: www.googleapis.com
Content-Type: application/json
Authorization: Bearer <token>
Content-Length: 597
Date: Wed, 08 Oct 2014 22:37:58 GMT
{
"acl": [
{
"entity": "user-84fac329bceSAMPLE777d5d22b8SAMPLE77d85ac2SAMPLE2dfcf7c4adf34da46",
"role": "OWNER",
"entityId": "84fac329bceSAMPLE777d5d22b8SAMPLE77d85ac2SAMPLE2dfcf7c4adf34da46"
},
{
"entity": "user-jane@gmail.com",
"role": "OWNER",
"email": "jane@gmail.com"
},
{
"entity": "group-gs-announce@googlegroups.com",
"role": "READER",
"email": "gs-announce@googlegroups.com"
}
]
}
XML API
The following cURL command applies an XML payload from the document acls.xml to an object named paris.jpg:
curl -X PUT --data-binary @acls.xml -H "Authorization: Bearer <token>" \
https://storage.googleapis.com/travel-maps/paris.jpg?acl
This is a PUT Object
request using the acl query string parameter and the corresponding XML document (in this case,
acls.txt). The request changes the ACL of an object named paris.jpg that is in a bucket named
travel-maps. The ACL grants jane@gmail.com FULL_CONTROL permission and it grants the
members of the gs-announce group READ permission on the object paris.jpg.
The details of the request are:
PUT /paris.jpg?acl HTTP/1.1
Host: travel-maps.storage.googleapis.com
Date: Sat, 20 Feb 2010 08:31:08 GMT
Content-Length: 589
Content-Type=application/xml
Authorization: Bearer <token>
<?xml version='1.0' encoding='utf-8'?>
<AccessControlList>
<Owner>
<ID>84fac329bceSAMPLE777d5d22b8SAMPLE77d85ac2SAMPLE2dfcf7c4adf34da46</ID>
</Owner>
<Entries>
<Entry>
<Permission>FULL_CONTROL</Permission>
<Scope type="UserById">
<ID>84fac329bceSAMPLE777d5d22b8SAMPLE77d85ac2SAMPLE2dfcf7c4adf34da46</ID>
</Scope>
</Entry>
<Entry>
<Scope type="UserByEmail">
<EmailAddress>jane@gmail.com</EmailAddress>
<Name>Jane</Name>
</Scope>
<Permission>FULL_CONTROL</Permission>
</Entry>
<Entry>
<Scope type="GroupByEmail">
<EmailAddress>gs-announce@googlegroups.com</EmailAddress>
</Scope>
<Permission>READ</Permission>
</Entry>
</Entries>
</AccessControlList>
The following examples show how to get the ACL of an existing object.
Google Developers Console
In the Google Developers Console, find the object and edit its permissions. See the image above for an example of object permissions.
gsutil
Use the gsutil acl get to return an object's ACL. To
return the ACL of the object paris.jpg, you can use:
gsutil acl get gs://travel-maps/paris.jpg
Example response:
[
{
"entity": "user-84fac329bceSAMPLE777d5d22b8SAMPLE77d85ac2SAMPLE2dfcf7c4adf34da46",
"entityId": "84fac329bceSAMPLE777d5d22b8SAMPLE77d85ac2SAMPLE2dfcf7c4adf34da46",
"role": "OWNER"
},
{
"email": "jane@gmail.com",
"entity": "user-jane@gmail.com",
"role": "OWNER"
},
{
"email": "gs-announce@googlegroups.com",
"entity": "group-gs-announce@googlegroups.com",
"role": "READER"
}
]
JSON API
You can retrieve an object's ACL with a
get request. The object ACL
is returned in JSON format, attached to the body of the response. You must have OWNER
permission to apply or retrieve ACLs on a bucket or object.
To return the ACL for the object paris.jpg, you can use
curl -X GET -H "Authorization: Bearer <token>" \
https://www.googleapis.com/storage/v1/b/travel-maps/o/paris.jpg?projection=full
Example response:
{
"kind": "storage#object",
"id": "travel-maps/paris.jpg/1412805837131000",
"selfLink": "https://www.googleapis.com/storage/v1/b/travel-maps/o/paris.jpg",
"name": "paris.jpg",
"bucket": "travel-maps",
...
"acl": [
{
...
"entity": "user-84fac329bceSAMPLE777d5d22b8SAMPLE77d85ac2SAMPLE2dfcf7c4adf34da46",
"role": "OWNER",
"entityId": "84fac329bceSAMPLE777d5d22b8SAMPLE77d85ac2SAMPLE2dfcf7c4adf34da46",
...
},
{
...
"entity": "user-jane@gmail.com",
"role": "OWNER",
"email": "jane@gmail.com",
},
{
...
"entity": "group-gs-announce@googlegroups.com",
"role": "READER",
"email": "gs-announce@googlegroups.com",
...
}
],
"owner": {
"entity": "user-84fac329bceSAMPLE777d5d22b8SAMPLE77d85ac2SAMPLE2dfcf7c4adf34da46",
"entityId": "84fac329bceSAMPLE777d5d22b8SAMPLE77d85ac2SAMPLE2dfcf7c4adf34da46"
},
...
}
You can also use the objectAccessControls resource get method to return individual entries in an object's ACL.
XML API
You can retrieve an object's ACL by using the acl query string
parameter in a GET Object request.
The ACLs are described in XML, attached to the
body of the response. You must have FULL_CONTROL permission to apply or retrieve ACLs
on a bucket or object.
To return the ACL for the object paris.jpg, you can use:
curl -X GET -H "Authorization: Bearer <token>" \
https://storage.googleapis.com/travel-maps/paris.jpg?acl
Example response:
<?xml version="1.0" encoding="UTF-8"?>
<AccessControlList>
<Owner>
<ID>84fac329bceSAMPLE777d5d22b8SAMPLE77d85ac2SAMPLE2dfcf7c4adf34da46</ID>
<Name>Owner Name</Name>
</Owner>
<Entries>
<Entry>
<Scope type="UserById">
<ID>84fac329bceSAMPLE777d5d22b8SAMPLE77d85ac2SAMPLE2dfcf7c4adf34da46</ID>
<Name>Name</Name>
</Scope>
<Permission>FULL_CONTROL</Permission>
</Entry>
<Entry>
<Scope type="UserByEmail">
<EmailAddress>jane@gmail.com</EmailAddress>
<Name>Jane</Name>
</Scope>
<Permission>FULL_CONTROL</Permission>
</Entry>
<Entry>
<Scope type="GroupByEmail">
<EmailAddress>gs-announce@googlegroups.com</EmailAddress>
</Scope>
<Permission>READ</Permission>
</Entry>
</Entries>
</AccessControlList>
You can also use the get method of the ObjectAccessControls resource to return a specific ACL entry.
Concentric permissions
When specifying ACLs in Google Cloud Storage, you do not need to
list multiple scopes to grant multiple permissions. Google Cloud Storage uses concentric permissions so
when you grant WRITER permission, you also grant READER permission, and if
you grant OWNER permission, you also grant READER and
WRITER permission.
When specifying an ACL using the Google Developers Console, JSON API, or gsutil, you can specify multiple
scopes for the same entry. The most permissive permission is the access granted to the scope.
For example, if you provide two entries for a user, one with READER permission
and one with WRITER permission on a bucket, the user will have
WRITER permission on the bucket.
In the XML API, it is not possible to provide two ACL entries with the same scope. For example,
granting a user READ
permission and WRITE permission on a bucket will result in an error. Instead, grant the user
WRITE permission which also grants the user READ permission.
Applying a predefined ACL
A predefined or canned ACL is an alias for a set of specific ACL entries that you can use to quickly
apply many ACL entries at once to a bucket or object. Predefined ACLs are defined for common
scenarios such as revoking all access permissions except for owner permission (predefined ACL
private), or making an object publicly readable (predefined ACL public-read).
The table below lists predefined ACLs that you can use and shows which ACL entries are applied for each predefined ACL. When using the table below, note that:
- For reference, bucket owner is the project owners group, and object owner is the user that created the object. If an object was created by an anonymous user, then the object owner is the project owners group.
- In the table, the JSON API descriptions of permissions,
OWNER,WRITER, andREADER, are used. The equivalent XML API scopes areFULL_CONTROL,WRITE, andREAD. - Predefined ACLs used with gsutil have the same names as those used in XML API. The JSON API names for predefined ACLs are different and are noted in parentheses.
