Security Advice for GCS Buckets
Almost every non-trivial website will have storage needs. As a Google Developer Advocate, I’ve been using Google Cloud Storage and talking to customers about their issues and difficulties with GCS. Security has come up a couple of times in these discussions. While I can’t tell you how to make your buckets and objects 100% secure, I can give you some basic advice that is pretty universally applicable. The vast majority of this information came from a week of research into the security of GCS buckets in a typical use case that I did in early December.
Keep Your Credentials to Yourself
I know it seems obvious that you shouldn’t share passwords, service accounts, API keys, or other secrets. Yet, leaked credentials are a common source of security issues. The accepted best practice is that each individual and each application should have their own credentials. This makes it easy to remove one person’s permissions without affecting any of the other users of the buckets. It also gives you visibility into who is doing what with your audit logging. But just assigning everyone an account isn’t sufficient. There have been high profile leaks because one engineer’s credentials got leaked. Ensure that credentials are getting stored securely enough for your use case. A piece of paper under your keyboard tray isn’t secure, but it is a lot more secure than checking credentials (or dotfiles) into a public source repository. And if you use password managers or check credentials into source then the credentials are only secure as the password manager or source repository.
Bucket Names are Discoverable
It wasn’t obvious to me when I started storing data in the cloud that bucket names are often discoverable by anyone. Complicating this is that in GCS and other cloud storage providers bucket names must be global unique. Under these constraints it feels like a good idea to put your project, company, application, or even personal credentials into the bucket name. I used to do this since it was easy to come up with a unique bucket name that had “aja-“ as a prefix. Once I realized that a sufficiently motivated individual could probe my buckets I took all personal information out of bucket names. Depending on you access the contents of a bucket the object name may also appear in URLs, and therefore in browser or firewall logs. Again, this is another good reason to not put secrets into object names. In the official storage best practices doc Google Cloud recommends using guids for bucket names if you need a lot of buckets.
Double Check Permissions
My last tip is to regularly audit permissions and ACLs. I’ve found misconfigured buckets when I double check permissions on my project. Maybe you were setting up the proof of concept and made your bucket globally readable while you sorted out the rest of the application. Most of us do stuff like that occasionally, but it becomes a problem if that bucket lives on into production with the same permissions.
With GCS most projects use IAM permissions, but you may need to use ACLs lists if you need to have different permissions for objects in the same bucket. When I was digging into GCS permissions, I discovered that I had made incorrect assumptions about what different scopes meant. For example, I had assumed the “AllAuthenticatedUsers” scope meant all the users of my cloud project. When I read the documentation, I realized that it meant anyone with a Google account. If I want to limit access to just collaborators on my project I can do that with other scopes.
Of course, many projects have valid reasons for making a bucket globally readable. Perhaps you are using the bucket to store assets for your web application, or maybe you are using a bucket to store a scientific data set that you are sharing with others. Just make sure that the permissions are appropriate for your use case and set a reminder to audit them every so often to ensure that your use case hasn’t changed.
This blog post only covers a few points. Before you take your app to production, I recommend reading more information on best practices for Google Cloud Storage on the Google Cloud site. That document is kept up to date, unlike a blog post.