Controlling Access to Google Cloud Storage
*Check out the updated version of this post, here*
Your data is important, so it’s worth taking the time to double-check who has access to it. With Google Cloud Storage, your data is private by default. To share access to that data, you’ve got a variety of options. To help you through that decision process, this guide covers the basics — and the differences — of those options.
Something to keep in mind before diving in: By default, access is managed at the object level, which means that a single bucket of storage can hold data objects with many varying levels of accessibility.
Three Basic Access Patterns
To start, let’s go over three basic access patterns for Google Cloud Storage:
1.All your data is private to just you and your projects: This is the default setting, and is the best choice for many systems and use cases.
2. Data Access is adjusted on a per-object or per-bucket level: With Google Cloud IAM, you can decide which users, groups, or projects could have access to an object or bucket, based on your own setup. This tends to be helpful in larger organizations with different access and privacy needs across teams.
3. Certain objects or buckets are allowed to be publicly accessible: This means anyone with the link to the object can access it — which makes Google Cloud Storage a great place to store assets for your applications to fetch from. This is also how you can provide a public endpoint that users can access.
Changing and Assigning Permissions
To change the access permissions for an object, you simply need to edit those permissions, either through the GSutil command line tool, or in the Cloud Console.
And to save time, you can even change the edit permissions for an entire bucket at once.
Other Types of Access Policies
Signed URLs and Signed Policy Documents
If you need someone to be able to access or upload to your bucket, but don’t need them to log in to their Google account, try a Signed URL or Signed Policy Document. A signed URL gives time-limited access to a URL to anyone with the link, regardless of if they have a Google account or not. Learn more about those here.
A Signed Policy Document specifies what can be uploaded to a bucket, and offers similar benefits of a Signed URL, but with additional upload characteristic parameters, like content type, size, etc. Check out this article for more information.
Authenticated Browsers
Authenticated Browsers can be used if you need a public endpoint, but also want more oversight and control over who has access. Like if you’re a construction company that needs to receive design proposals from several different clients, or if you’re a photography company that needs to share information with a variety of different users and groups. In both situations, you need specific access granted for the information.
Authenticated browsers work by using cookies to track and verify a user’s identity and level of access.
Users will have to login to a Google account in order to get access to specified data, and the process is managed via the use of cookies. In a matter of clicks, you can grant a user access and send them a URL to the object:
Regardless of your access scenario adjusting permissions for objects can be done either through GSUTIL command line tool, our client libraries or in the Google Cloud console with just a few clicks .
Authenticated Browsers work with other access management in Cloud Platform, and as your access complexity grows, you’ll want to start spending more time leaning on Cloud IAM and Access Control Lists (ACLs) check out this article for further details about authenticated browsers.
Cloud Identity and Access Management (Cloud IAM)
Cloud IAM provides enterprise-grade access control to all of Cloud; letting you adjust permissions in a hierarchical manner and assign access to the resources in your Cloud Platform project. A resource can be anything from your Cloud Storage Bucket, to the Objects within the bucket — even other Cloud Platform entities such as a Compute Engine instance.
With Cloud IAM, you can adjust policies and permissions on the object or member level, making it flexible enough to suit your needs for specific situations, as well as across larger org-wide policies.
You can read more about Cloud IAM best practices, and helpful details like different types of members here.
Access Control Lists (ACLs)
While Cloud IAM alone covers most of your needs, there are situations where an Access Control List may simplify your Cloud IAM setup. ACLs let you grant access to individual objects within a bucket, and are a bit more intensive when it comes to setup.
Each ACL is applied to an object or bucket, and consists of one or more entries. Each entry contains the details around what actions can be taken, and by whom. There are predefined ACLs you can use to quickly apply a commonly useful set of permissions to a bucket or object. Or you can always create your own, for example: to give everyone in a different department access to a specific bucket of data.
Default ACLs will be applied to any object within a bucket that does not have a specific ACL associated with it. The initial value of the default ACL is set to private for that project, and will impact usage accordingly. You can learn more about the specifics surrounding when and how to create an Access Control List in this article.
Bucket Policy Only
If you want to assign access based on a bucket (rather than the default object level we mentioned above), and need ACLs to be suspended, you can enable Bucket Policy Only. You can enable this upon creation, or by clicking “enable” on a particular bucket. This will help you adjust access uniformly based on that bucket, and will impact any other permissions from other Access Management Sources. This feature can be very helpful for certain use cases, but make sure you read up on the how-to and associated restrictions in this article.
After thoroughly controlling access to your data, you’re probably ready to start doing more, and I fully support that! Check out the next blog for more information about how to manage your data.
