In previous blog posts, we discussed security around Azure and AWS cloud solutions and now it’s time to look at the third big contestant, Google Cloud Platform (GCP). To make things clear, we are going to define some Google Cloud Platform (GCP) concepts and cover Identity and Access Management, Secure Networking and Data Loss Protection.
Permissions determine what operations are allowed on a resource. In the GCP IAM world, permissions are represented in the form of <service>.<resource>.<verb>, for example pubsub.subscriptions.consume.
A role is a collection of permissions. You cannot assign a permission to the user directly; instead you grant them a role.
You can grant roles to users by creating a GCP IAM policy, which is a collection of statements that define who has what type of access. A policy is attached to a resource and is used to enforce access control whenever that resource is accessed. For more info, see policy overview.
GCP IAM Role Types
There are three types of roles in GCP IAM:
Primitive roles, which include the Owner, Editor, and Viewer roles that existed prior to the introduction of GCP IAM. TIP: Don’t use primitive roles in GCP IAM policies, and never grant primitive roles on an organization, primitive roles gives an identity a lot of power.
Custom roles, which provide granular access according to a user-specified list of permissions
Now that we’ve established some concepts, let’s look at the major components of GCP and their implications towards security.
Identity Access Management
The first thing that we must think about for cloud security is Identity and Access Management (IAM), especially because GCP, Azure, and AWS implements IAM, but each of them in a different way. Here we are going to try to explain how Google implements IAM on their cloud.
Principle of Least Privilege
It is important to keep in mind is that GCP IAM implements the security principle of least privilege. What does this mean? It means giving users only the necessary access to the resources they are using and nothing more. So, if a user needs to be able to access to a VM, you give him the appropriate roles for that task (turn it on/off) but you don’t give them access to other tasks like taking a snapshot or editing the VM’s properties.
In GCP IAM, you grant access to members. Members can be of the following types:
Any email address that is associated with a Google account can be an identity, including gmail.com or other domains.
A service account is associated to an application instead of a user, so if you run code on GCP, you specify on which service account the code should run.
Pro Tip: Create descriptive Service Accounts, such that you know the purpose of those accounts. Also, be sure to protect service account keys with Cloud KMS and store them encrypted in Cloud Storage or some other storage repository that doesn’t have public access. Finally, ensure that you are rotating your keys on a regular basis, such as 90 days or less.
A Google group is a named collection of Google accounts and service accounts. Every group has a unique email address that is associated with the group. It’s useful to apply policies to a collection of users.
G Suite domain
A G Suite domain represents a virtual group of all the Google accounts that have been created in an organization’s G Suite account. Like Google groups, G Suite domains cannot be used to establish identity, but they enable convenient permission management.
Cloud Identity domain
A Cloud Identity domain is like a G Suite domain because it represents a virtual group of all Google accounts in an organization. However, Cloud Identity domain users don’t have access to G Suite applications and features. For more information, see About Cloud Identity.
A special identifier that groups all users that are authenticated on the GCP on your project
This represents anyone who is on the internet, including authenticated and unauthenticated users.
Pro TIP: Instead of applying permissions directly to users, add users to well-defined Groups and assign Roles to those Groups, thereby granting permission to the appropriate resources only. Make sure to use custom roles, as built-in roles could change in scope.
A Security Checklist for GCP IAM
Don’t use default service accounts. They have primitive roles.
Don’t let your service accounts have more than two active keys. Limiting the amount of accounts using it applies the principle of least privilege
Always use custom roles to monitor all external identities in your organization.
Add external users to Cloud IAM policies as individual users and don’t add them to groups.
When it comes to network security, each cloud provider offers similar tools to help you protect your network, but there are some principles that apply globally:
VPC for your network
GCP uses VPC (Virtual Private Cloud/Network) and subnets to allow you to organize your resources the best way possible. You can group your resources to use the same subnet and also isolate them, so nobody else has access outside the resources on that group. This can limit the attack surface for someone who wants to target your company.
Also, you can find Shared VPC, which allows you to connect VPCs that you have isolated in a secured way, by using only internal IPs and not exposing anything to the Internet while maintaining your resource separation.
Firewall rules applies to VPC, and these rules are the ones that provides the security for your resources. Some tips for firewall rules are:
If a VM or database doesn’t need to communicate to internet (because it’s only used by others VMs on your cloud), create a rule that accepts incoming traffic just from specific resources, limiting the outside communication.
VPC comes with implied rules (they exist but are not shown). The first one is that outgoing traffic from a resource is allowed to everyone (0.0.0.0/0), and the second one is that incoming traffic is denied from everyone.
If an instance only needs traffic from a specific port, for example a webserver listening on port 80, only allow traffic on that port, and if you can, specify also the subnet where incoming traffic is allowed.
You should never have a firewall rule allowing incoming traffic from any IP range on any port. Resources should have clear rules when it comes to incoming traffic.
Also, outgoing traffic should be limited as well in case you have a breach on your resources, to prevent data from being stolen from your cloud.
Data Loss Prevention
Data Loss Prevention (DLP) is a service that GCP provides to users to help them with their sensitive data. If your company allows users to upload documents and pictures to your Google cloud, you can use DLP to see if they are exposing something that they shouldn’t.
DLP provides an API and you can interact with it programmatically using Cloud DLP Client Library using your favorite language.
DLP allows you to inspect different kind of data, such as text strings, images and text files.
When you interact with DLP and depending on the parameters you sent to it, DLP scans your content and check if there is sensitive data exposed by applying different techniques and known patterns to identify valuable data. This can also do some inspect Cloud Storage files and BigQuery tables.
You can also use DLP to not only detect sensitive data but also to hide that data is it is found. You just give DLP the data you have, what is going to be the placeholder that is going to replace the sensitive data and what type of data you want to hide. For example, to hide an email, you will make a request like this:
And then, DLP would respond something like this:
You can schedule when Cloud DLP runs jobs by creating job triggers. A job trigger is an event that automates the creation of DLP jobs to scan Google Cloud Platform storage repositories, including Cloud Storage buckets, BigQuery tables, and Cloud Datastore kinds. I hope this has given you a look at some of the important concepts, systems, and features available in the Google Cloud Platform to support running your workloads securely in the cloud. Next time we will finish our look at GCP with a focus on more advanced features such as Cloud Armor, Cloud Security Scanner, and Stackdriver.