Jump to Content
Containers & Kubernetes

Exploring Container Security: Run what you trust; isolate what you don’t

February 12, 2020
Aparna Sinha

Director of Product Management

Sampath Srinivas

Director, Product Management, Google Cloud

Anchoring on Containers

Learn why Google Cloud’s container offerings lead the market


From vulnerabilities to cryptojacking to well, more cryptojacking, there were plenty of security events to keep container users on their toes throughout 2019. With Kubernetes being used to manage most container-based environments (and increasingly hybrid ones too), it’s no surprise that Forrester Research, in their 2020 predictions, called out the need for “securing apps and data in an increasingly hybrid cloud world.” 

On the Google Cloud container security team, we want your containers to be well protected, whether you’re running in the cloud with Google Kubernetes Engine or hybrid with Anthos, and for you to be in-the-know about container security. As we kick off 2020, here’s some advice on how to protect your Kubernetes environment, plus a breakdown of recent GKE features and resources.

Run only what you trust, from hardware to services

Many of the vulnerabilities we saw in 2019 compromised the container supply chain or escalated privileges through another overly-trusted component. It’s important that you trust what you run, and that you apply defense-in-depth principles to your containers. To help you do this, Shielded GKE Nodes is now generally available, and will be followed shortly by the general availability of Workload Identity--a way to authenticate your GKE applications to other Google Cloud services that follows best practice security principles like defense-in-depth.

Let’s take a deeper look at these features.

Shielded GKE Nodes
Shielded GKE Nodes ensures that a node running in your cluster is a verified node in a Google data center. By extending the concept of Shielded VMs to GKE nodes, Shielded GKE Nodes improves baseline GKE security in two respects:

  • Node OS provenance check: A cryptographically verifiable check to make sure the node OS is running on a virtual machine in Google data center

  • Enhanced rootkit and bootkit protection: Secure and measured boot, virtual trusted platform module (vTPM), UEFI firmware, and integrity monitoring

You can now turn on these Shielded GKE Nodes protections when creating a new cluster or upgrading an existing cluster. For more information, read the documentation.

Workload Identity
Your GKE applications probably use another service--like a data warehouse--to do their job. For example, in the vein of “running only what you trust,” when an application interacts with a data warehouse, that warehouse will require your application to be authenticated. Historically the approaches to doing this haven’t been in line with security principles—they were overly permissive, or had the potential for a large blast radius if they were compromised. 

Workload Identity helps you follow the principle of least privilege and reduce that blast radius potential by automating workload authentication through a Google-managed service account, with short-lived credentials. Learn more about Workload Identity in the beta launch blog and the documentation. We will soon be launching general availability of Workload Identity.

Stronger security for the workloads you don’t trust
But sometimes, you can’t confidently vouch for the workloads you’re running. For example, an application might use code that originated outside your organization, or it might be a  software-as-a-service (SaaS) application that ingests input from an unknown user. In the case of these untrusted workloads, a second layer of isolation between the workload and the host resources is part of following the defense-in-depth security principle. To help you do this, we’re releasing the general availability of GKE Sandbox.  

GKE Sandbox
GKE Sandbox uses the open source container runtime gVisor to run your containers with an extra layer of isolation, without requiring you to change your application or how you interact with the container. gVisor uses a user space kernel to intercept and handle syscalls, reducing the direct interaction between the container and the host, and thereby reducing the attack surface. However, as a managed service, GKE Sandbox abstracts away these internals, giving you  single-step simplicity for multiple layers of protection. Get started with GKE Sandbox. 

Up your container security knowledge

As more companies use containers and Kubernetes to modernize their applications, decision makers and business leaders need to understand how they apply to their business—and how they will help keep them secure.  

Core concepts in container security
Written specifically for readers who are new to containers and Kubernetes, Why Container Security Matters to Your Business takes you through the core concepts of container security, for example supply chain and runtime security. Whether you’re running Kubernetes yourself or through a managed service like GKE or Anthos, this white paper will help you connect the dots between how open-source software like Kubernetes responds to vulnerabilities and what that means for your organization.  

New GKE multi-tenancy best practices guide
Multi-tenancy, when one or more clusters are shared between tenants, is often implemented as a cost-saving or productivity mechanism. However, incorrectly configuring the clusters to have multiple tenants, or the corresponding compute or storage resources, can not only deny these cost-savings, but open organizations to a variety of attack vectors. We’ve just released a new guide, GKE Enterprise Multi-tenancy Best Practices, that takes you through setting up multi-tenant clusters with an eye towards reliability, security, and monitoring. Read the new guide, see the corresponding Terraform modules, and improve your multi-tenancy security.

Learn how Google approaches cloud-native security internally
Just as the industry is transitioning from an architecture based on monolithic applications to distributed “cloud-native” microservices, Google has also been on a journey from perimeter-based security to cloud-native security.

In two new whitepapers, we released details about how we did this internally, including the security principles behind cloud-native security. Learn more about BeyondProd, Google’s model for cloud-native security; and about Binary Authorization for Borg, which discusses how we ensure code provenance and use code identity.

Let 2020 be your year for container security

Security is a continuous journey. Whether you’re just getting started with GKE or are already running clusters across clouds with Anthos, stay up to date with the latest in Google’s container security features and see how to implement them in the cluster hardening guide.

Posted in