Securing any cloud is hard. In certain respects, securing Google Cloud Platform, or GCP, is especially challenging.

That’s not because of any deficiency in GCP itself. It’s an established, robust, reliable cloud platform that powers millions of workloads. Rather, it’s the fact that GCP is in most ways the newest of the “Big Three” public cloud platforms that can make it harder to secure. There are fewer security tools out there designed to cater to GCP specifically, and less advice on GCP security best practices.

GCP is also technically different from clouds like Azure and AWS in certain important ways. For instance, one big differentiator is that GCP leans heavily on Kubernetes, which it uses as the basis for its hybrid cloud management framework (Anthos) in addition to a managed container service (Google Kubernetes Engine).

With all of the above in mind, this article walks through what to know about GCP cloud security. We’ll discuss shared responsibility in Google Cloud, the native security controls that Google provides for cloud workloads, and best practices for securing applications and data hosted in Google Cloud.

GCP Shared Responsibility Model

Like all major public clouds, GCP adopts a shared responsibility model. Under this model, some security responsibilities fall to the customer and some to Google Cloud. Others are shared.

The exact security responsibility arrangements vary between cloud services and configurations – and Google offers an 87-page document that breaks it all down if you want to know the details. In general, shared responsibility on GCP can be summarized as follows:

• Google secures physical infrastructure, including physical networks, servers, and storage media. The exception is any on-premises infrastructure connected to GCP through a hybrid cloud architecture.
• Customers secure workloads that they deploy on Google Cloud. These include resources such as the operating systems that customers install on cloud VMs, virtual networking configurations they set up, containers they deploy through GKE, and any data they upload to GCP Cloud Storage.
• Google shares security responsibility with customers in the case of GCP managed services. For example, if you use GKE, the GCP managed Kubernetes service, Google secures the infrastructure components required to run clusters, while customers secure most of the Kubernetes components (like the API) and any applications they deploy through GKE.

GCP Security and Compliance Challenges

Again, GCP is just as secure as any other major public cloud. But, it’s worth noting the ways in which securing workloads on GCP can be particularly challenging.

A Smaller Cloud Ecosystem

One challenge is that, as we noted above, GCP is a younger cloud in most respects than Azure and AWS. It has also historically had a lower market share. Both of these factors mean that the cloud ecosystem as a whole hasn’t catered as much to GCP as it has to other clouds. While many modern cloud-native security platforms do fully support GCP, others work only with AWS and Azure. In addition, many engineers are likely to have less experience working with GCP’s native security tooling, such as its Identity and Access Management (IAM) framework, than they are with the equivalent services running on AWS and Azure.

Multicloud and Hybrid Cloud Investments

GCP also arguably focuses more on multicloud and hybrid cloud use cases than AWS and Azure, whose market dominance makes compatibility with external environments less important (although AWS and Azure do both offer hybrid and multicloud integrations).

This tendency is borne out by the fact that, for example, GCP was the first major public cloud to offer a hybrid cloud framework, Anthos, that works with virtually any type of on-premises infrastructure. The Azure and AWS equivalents – Azure Stack and AWS Outposts – are more restrictive than Anthos in most respects.

From a security perspective, GCP’s hybrid and multicloud leaning presents a challenge in the sense that GCP users are more likely to integrate their GCP workloads with external environments. This makes it harder to rely on GCP’s native security tooling alone (which doesn’t typically support third-party environments) to secure workloads. It also increases some of the challenges associated with securing the network infrastructure and APIs that connect GCP to external resources.

These challenges are all eminently solvable, but it’s important to recognize the special requirements of GCP security in order to plan the most effective security strategy for Google Cloud.

GCP Cloud Security Best Practices

In general, managing the security risks of Google Cloud hinges on the same approach you’d take to securing any cloud, including:

• Use GCP IAM: IAM is one of the most powerful tools for securing cloud workloads. Take full advantage of Google Cloud’s IAM framework to enforce least privilege within your GCP environment. For example, a GCP IAM policy like the following (which is defined in YAML) grants permissions to list and view storage buckets to a custom role:

description: My custom role description.
etag: BwVkBkbfr70=
includedPermissions:
- iam.roles.get
- iam.roles.list
- storage.buckets.get
- storage.buckets.list
name: projects/my-project-id/roles/myCompanyAdmin
stage: ALPHA
title: My Company AdminCode language: PHP (php)

In addition, audit your IAM policies to detect misconfigurations that could lead to security breaches.

• Isolate your cloud networks: Using resources like GCP Virtual Private Cloud, isolate unrelated workloads within their own private networks to mitigate the risk that security issues will spill over from one workload to another.
• Use labels and tags: GCP lets you organize your workloads using labels and tags. While a lack of labeling or tagging is not a security risk per se, resources that aren’t properly organized are more likely to be breached because you may forget that they are there or fail to include them in audits.
• Isolate sensitive data: Know where sensitive data (such as data that contains personally identifiable information) exists within your GCP environment. Consider using Google Cloud DLP to discover sensitive data in locations where you may be overlooking it.
• Understand managed services responsibility: With managed services in particular, it’s easy to make false assumptions about how much of a role the cloud provider will play in security, largely because this is a nuanced topic and vendor responsibilities can vary from one service to another. Be sure you understand the unique aspects of each managed service you use.

Beyond these practices, you may wish to take additional steps to address the special security challenges of Google Cloud. Consider the following strategies:

• Use external security monitoring and auditing tools: While GCP provides some tools, such as Security Command Center, to help secure cloud resources, their major limitation, as noted above, is that they generally only work for workloads running in GCP itself. If you operate a hybrid or multicloud environment – or you just want deeper security monitoring, analytics, and alerting features than the native GCP tooling offers – consider using a third-party security platform that can work across multiple cloud and on-premises environments.
• Invest in Kubernetes security: Because GCP leans especially heavily on Kubernetes as the foundation for some of its major services, mastering Kubernetes security is particularly important for GCP users – especially those that use Kubernetes-based frameworks, like Anthos. 
• Understand managed vs. unmanaged Kubernetes security: It’s important to note that, while you can run Kubernetes as a managed service on GCP via GKE, you can also set up Kubernetes yourself on your own infrastructure. In the latter case, all Kubernetes security responsibility falls to you. In other words, learn the nuances of security responsibility within different types of Kubernetes deployment models within GCP.

GCP Container Security Best Practices

We’ve said a lot about the central role that Kubernetes security plays in GCP security. But how do you actually secure Kubernetes and containers running on Google Cloud?

A complete answer to that question is beyond the scope of this article, but basic best practices to follow include:

• Secure container images: Google Cloud won’t automatically scan container images for you to find malware or vulnerabilities. You’ll need to do that yourself before deploying images into GKE or another container-based environment hosted in GCP.
• Use Kubernetes security auditing: Kubernetes security auditing is a powerful feature for keeping tabs on what is happening inside your clusters and catching potential abuses early on. Make sure you enable security auditing and analyze audit events within a tool that can detect suspicious behavioral patterns.
• Audit your container environments: Kubernetes security audits only monitor requests to the Kubernetes API. You should also use external tools to audit your container software stack configuration as a whole by checking for outdated software versions, insecure access control configurations, vulnerable runtime versions, and so on.
• Restrict container permissions: Using tooling like Kubernetes security contexts, restrict which resources your container can access and isolate containers from each other.

Start With the Fundamentals

GCP security is a complex topic, but it can be broken down into some relatively basic fundamentals. It starts with following the security and compliance best practices that you would enforce in any type of cloud environment. From there, you’ll also want to implement security controls that address the special characteristics of GCP, such as its Kubernetes-centric focus and its tendency to be part of a multi cloud or hybrid cloud architecture.