Exploring container security: Navigate the security seas with ease in GKE v1.15

Your container fleet, like a flotilla, needs ongoing maintenance and attention to stay afloat—and stay secure. In the olden days of seafaring, you grounded your ship at high tide and turned it on its side to clean and repair the hull, essentially taking it “offline.” We know that isn’t practical for your container environment however, as uptime is as important as security for most applications. 

Here on the Google Kubernetes Engine (GKE) team, we’re always hard at work behind the scenes to provide you with the latest security patches and features, so you can keep your fleet safe while retaining control and anticipating disruptions.

As GKE moved from v1.12 to v1.15 over the past year, here’s an overview of what security changes we’ve made to the platform, to improve security behind the scenes, and with stronger defaults, as well as advice we added to the GKE hardening guide.

Behind-the-scenes hardening in GKE

A lot of our security recommendations come down to a simple principle: implement and expose fewer items in your infrastructure, so there’s less for you to secure, maintain, and patch. In GKE, this means paring down controls to only what your application actually needs and removing older implementations or defaults. Let’s take a deeper look at the changes we made this year.

Distroless images

Behind the scenes, we’re continually hardening and improving GKE. A major undertaking in the past several months has been rebasing GKE master and daemonset containers on top of distroless base images. Distroless images are limited to only the application and its runtime dependencies—they’re not a full Linux distribution, so there are no shells or package managers. And because these images are smaller, they’re faster to load, and have a smaller attack surface. By moving almost all Kubernetes components to distroless images in Kubernetes 1.15 and 1.16, this helps to reduce the signal-to-noise ratio in vulnerability scanning, and makes it simpler to maintain Kubernetes components. By the way, you should also consider moving your container application images to distroless images!

Locking down system:unauthenticated access to clusters

Kubernetes authentication allows certain cluster roles to have access to cluster information by default, for example, to gather metrics about cluster performance. This specifically allows unauthenticated users (who could be from anywhere on the public internet!) to read some unintended information if they gain access to the cluster API server. We worked in open-source to change this in Kubernetes 1.14, and introduced a new discovery role system:public-info-viewer explicitly meant for unauthenticated users. We also removed system:unauthenticated access to other API server information. 

Ongoing patching and vulnerability response

Our security experts are part of the Kubernetes Product Security Committee, and help manage, develop patches for, and address newly discovered Kubernetes vulnerabilities. On GKE, in addition to Kubernetes vulnerabilities, we handle other security patches—in the past year, these included critical patches to the Linux kernel, runc, and the Go programming language—and when appropriate, publishing a security bulletin detailing the changes.

Better defaults in GKE

Among the more visible changes, we’ve also changed the defaults for new clusters in GKE to more secure options, to allow newer clusters to more easily adopt these best practices. In the past several releases, this has included enabling node auto-upgrade by default, removing the Kubernetes dashboard add-on, removing basic authentication and client certs, and removing access to legacy node metadata endpoints. These changes apply to any new GKE clusters you create, and you can still opt to use another option if you prefer.

new clusters in GKE.png
Defaults for new clusters in GKE have been improving over releases in the past several years, to improve security

Enabling node auto-upgrade

Keeping the version of Kubernetes up-to-date is one of the simplest things you can do to improve your security. According to the shared responsibility model, we patch and upgrade GKE masters for you, but upgrading the nodes remains your responsibility. Node auto-upgrade automatically provides security patches, bug fixes and other upgrades to your node pools, and ensures alignment with your master version to avoid unsupported version skew. As of November, node auto-upgrade is enabled by default for new clusters. Nothing has changed for pre-existing clusters though, so please consider enabling node auto-upgrade manually or upgrading yourself regularly and watching the Security Bulletins for information on recommended security patches. With release channels, you can subscribe your cluster to a channel that meets your business needs, and infrastructure requirement. Release channels take care of both the masters and nodes, and ensures your cluster is up to date with the latest patch version available in the chosen channel.

Locking down the Kubernetes Dashboard

The open-source Kubernetes web UI (Dashboard) is an add-on which provides a web-based interface to interact with your Kubernetes deployment, including information on the state of your clusters and errors that may have occurred. Unfortunately, it is sometimes left publicly accessible or granted sensitive credentials, making it susceptible to attack. Since the Google Cloud Console provides much of the same functionality for GKE, we’ve further locked down the Dashboard to better protect your clusters. For new clusters created with:

  • GKE v1.7, the Dashboard does not have admin access by default.
  • GKE v1.10, the Dashboard is disabled by default.
  • GKE v1.15 and higher, the Kubernetes web UI add-on Dashboard is no longer available in new GKE clusters.

You can still run the dashboard if you wish, following the Kubernetes web UI documentation to install it yourself.

Improving authentication

There are several methods of authenticating to the Kubernetes API server. In GKE, the supported methods are OAuth tokens, x509 client certificates, and static passwords (basic authentication). GKE manages authentication via gcloud for you using the OAuth token method, setting up the Kubernetes configuration, getting an access token, and keeping it up to date. Enabling additional authentication methods, unless your application is using them, presents a wider surface of attack. Starting in GKE v1.12, we disabled basic authentication and legacy client certificates by default for new clusters, so that these credentials are not created for your cluster. For older clusters, make sure to remove the static password if you aren’t using it.

Disabling metadata server endpoints

Some attacks against Kubernetes use access to the VM’s metadata server to extract the node’s credentials; this can be particularly true for legacy metadata server endpoints. For new clusters starting with GKE v1.12, we disabled these endpoints by default. Note that Compute Engine is in the process of turning down these legacy endpoints. If you haven’t already, you may use the check-legacy-endpoint-access tool to help discover if your apps should be updated and migrated to the GA v1 metadata endpoints, which include an added layer of security that can help customers protect against vulnerabilities .

Our latest and greatest hardening guide

Even though we keep making more and more of our security recommendations the default in GKE, they primarily apply to new clusters. This means that even if you’ve been continuously updating an older cluster, you’re not necessarily benefitting from these best practices. To lock down your workloads as best as possible, make sure to follow the GKE hardening guide. We’ve recently updated this with the latest features, and made it more practical, with recommendations for new clusters, as well as recommendations for GKE On-Prem

It’s worth highlighting some of the newer recommendations in the hardening guide for Workload Identity and Shielded GKE Nodes.

Workload Identity

Workload Identity is a new way to manage credentials for workloads you run in Kubernetes, automating best practices for workload authentication, and removing the need for service account private keys or node credential workarounds. We recommend you use Workload Identity over other options, as it replaces the need to use metadata concealment, and protects sensitive node metadata.

Shielded GKE Nodes

Shielded GKE Nodes is built upon Shielded VMs and further protects node metadata, providing strong, verifiable node identity and integrity for all the GKE nodes in your cluster. If you’re not using third-party kernel modules, we also recommend you enable secure boot to verify the validity of components running on your nodes and get enhanced rootkit and bootkit protections.

The most secure GKE yet

We’ve been working hard on hardening, updating defaults, and delivering new security features to help protect your GKE environment. For the latest and greatest guidance on how to bolster the security of your clusters, we’re always updating the GKE hardening guide.

Exploring container security: Day one Kubernetes decisions

Congratulations! You’ve decided to go with Google Kubernetes Engine (GKE) as your managed container orchestration platform. Your first order of business is to familiarize yourself with Kubernetes architecture, functionality and security principles. Then, as you get ready to install and configure your Kubernetes environment (on so-called day one), here are some security questions to ask yourself, to help guide your thinking.

  • How will you structure your Kubernetes environment? 

  • What is your identity provider service and source of truth for users and permissions?

  • How will you manage and restrict changes to your environment and deployments? 

  • Are there GKE features that you want to use that can only be enabled at cluster-creation time?

Ask these questions before you begin designing your production cluster, and take them seriously, as it’ll be difficult to change your answers after the fact. 

Structuring your environment

As soon as you decide on Kubernetes, you face a big decision: how should you structure your Kubernetes environment? By environment, we mean your workloads and their corresponding clusters and namespaces, and by structure we mean what workload goes in what cluster, and how namespaces map to teams. The answer, not surprisingly, depends on who’s managing that environment.

If you have an infrastructure team to manage Kubernetes (lucky you!), you’ll want to limit the number of clusters to make it easier to manage configurations, updates and consistency. A reasonable approach is to have separate clusters for production, test, and development. 

Separate clusters also make sense for sensitive or regulated workloads that have substantially different levels of trust. For example, you may want to use controls in production that would be disruptive in a development environment. If a given control doesn’t apply broadly to all your workloads, or would slow down some development teams, segment them out into separate clusters and give each dev team or service its own namespace within a cluster.

If there’s no central infrastructure team managing Kubernetes–if it’s more “every team for itself”—then each team will typically run its own cluster. This means more work and responsibility for them enforcing minimum standards—but also much more control over which security measures they implement, including upgrades. 

Setting up permissions

Most organizations use an existing identity provider, such as Google Identity or Microsoft Active Directory, consistently across the environment, including for workloads running in GKE. This allows you to manage users and permissions in a single place, avoiding potential mistakes like accidentally over-granting permissions, or forgetting to update permissions as users’ roles and responsibilities change.

What permissions should each user or group have in your Kubernetes environment? How you set up your permission model is strongly tied to how you segmented your workloads. If  multiple teams share a cluster, you’ll need to use Role-Based Access Control (RBAC) to give each team permissions in their own namespaces (some services automate this, providing a self-service way for a team to create and get permissions for its namespace). Thankfully, RBAC is built into Kubernetes, which makes it easier to ensure consistency across multiple clusters, including different providers. Here is an overview of access control in Google Cloud

Deploying to your Kubernetes environment

deploying your k8.png

In some organizations, developers are allowed to deploy directly to production clusters. We don’t recommend this. Giving developers direct access to a cluster is fine in test and dev environments, but for production, you want a more tightly controlled continuous delivery pipeline. With this in place, you can set up steps to run tests, ensure that images meet your policies, scan for vulnerabilities, and finally, deploy your images. And yes, you really should set up these pipelines on day one; it’s hard to convince developers who have always deployed to production to stop doing so later on.

Having a centralized CI/CD pipeline in place lets you put additional controls on which images can be deployed. The first step is to consolidate your container images into a single registry such as Container Registry, typically one per environment. Users can check images into a test registry, and once tests pass and they’re promoted to the production registry, push them to production.

We also recommend that you only allow service accounts (not people) to deploy images to production and make changes to cluster configurations. This lets you audit service account usage as part of a well-defined CI/CD pipeline. You can still give someone access if necessary, but in general it’s best to follow the principle of least privilege when granting service account permissions, and ensure that all administrative actions are logged and audited. 

Features to turn on from day one

A common day-one misstep is failing to enable certain security features that you might need down the road at cluster-creation time, because you’ll have to migrate your cluster once it’s up and running to turn them on. There are some GKE security features that you can’t turn on in an existing cluster that aren’t turned on by default, for example private clusters and 

Google Groups for GKE. Rather than trying to make a cluster you’ve used to experiment with these different features production-ready,  a better plan is to create a test cluster, make sure its features work as intended, resolve issues, and only then make a real cluster with your desired configurations. 

As you can see, there’s a lot to keep in mind when setting up GKE. Keep up to date with the latest advice and day two to-dos with the GKE hardening guide.

Exploring Container Security: Vulnerability management in open-source Kubernetes

When it comes to open source software (OSS) like Kubernetes, some people get nervous not knowing everyone who’s worked on the code in the project. “How can I trust something when anyone can contribute?” “If there’s a vulnerability, who’s paying attention?”

In fact, many OSS projects have robust security teams and rigorous vulnerability management processes, just like you’d expect to find in proprietary software. For Kubernetes, a dedicated Product Security Committee oversees the security response process. Learning about this process will give you a better understanding about the project, what to do if you suspect an issue, and your role in vulnerability response as a downstream Kubernetes user.

The Product Security Committee is a group of core maintainers, many with security-specific roles, nominated by other core maintainers and technical advisors within the community. The Committee’s role is to respond to any and all emails about a potential vulnerability, according to a documented response process. Here’s an overview.

1. Triage the disclosure 
When the team receives a disclosure, it begins investigating whether the submission is a real issue or just a bug without security implications. If the committee confirms that it’s an issue, it then leads the development and release of a patch and notifies the community. 

2. Assess the impact of the vulnerability
One key initial step is to determine a vulnerability’s potential impact. This is usually represented as a CVSS score and the documented severity criteria for Kubernetes vulnerabilities. This score looks at criteria like how easily the issue can be exploited, the consequences if it is exploited, and the privileges required to exploit it. A score under 4.0 is considered low; between 4.0 and 7.0 is medium; between 7.0 and 9.0 is high, and above 9.0 is critical. This CVSS score acts as a rough barometer for how issues should be prioritized and with what urgency, with the caveat that the vulnerability’s severity can vary depending on the specific Kubernetes deployment configuration and environment.

3. Generate a fix
Next, the Product Security Committee works with the relevant developers to generate a fix. If the vulnerability involves components from other open source projects, the team works with security groups within those projects. 

There are times when a security fix can happen in the open, as part of a normal patch release. But if the vulnerability is severe enough, the patch will be developed and tested in private. At this point, only those who need to know should be aware of the vulnerability; you wouldn’t want someone with malicious intent to have early knowledge of an unpatched issue.

For fixes that follow the private release process (and some that don’t), the release of a security patch will include an explanatory announcement to kubernetes-security-announce. And when necessary, a retrospective or postmortem is also released to the Kubernetes community, spelling out the steps taken, response timeline, and any other relevant details. 

4. Roll out the fix
The next step is to roll out notifications to certified Kubernetes distributors. Because distributors are responsible for what end users receive, it’s important that they have the opportunity to patch early (if a patch is needed) and prepare their own notifications. Like many open source projects, Kubernetes has a private list of distributors who get embargoed security notifications; anyone who meets the criteria can sign up for these messages. 

So what does all this mean for you as a Kubernetes user
First of all, make sure your team knows about the Product Security Committee’s process—it should help anyone who’s unsure about open source security feel more confident in Kubernetes. The Product Security Committee is a robust and responsive group of Kubernetes and security experts working on your behalf, complete with an on-call rotation during working hours. 

Second, if you’re deploying a container on Kubernetes and you notice something that makes you suspect a security issue, you should notify the Product Security Committee right away, safe in the knowledge that it’ll follow a prescribed process to get to the bottom of things. For more information about when and how to report a vulnerability, check out Kubernetes Security and Disclosure Information

It’s also important to know your provider’s communication policies with regard to vulnerabilities. To that end, be sure you know the answer to the following questions:

  • If there’s a problem, when will my provider contact me?

  • Where are security bulletins posted for the services I’m consuming?

  • How can I find out when patches will be available for those services?

  • Where can I find information about vulnerabilities for what I run in my environment?

When appropriate, Google Cloud publishes security bulletins for Google Kubernetes Engine (GKE) and sends email notifications to affected users. If we can make patches on their behalf or the problem is one for which Google Cloud is responsible, we’ll take care of fixes. GKE users should defer to the GKE security bulletins as their source of truth; it’s updated whenever a new issue is severe enough to warrant attention.

In short, as a Kubernetes end user you should:

  1. Share the Kubernetes response and reporting processes with your team
  2. Report any future suspected issues through the Kubernetes disclosure process
  3. Learn about your provider’s disclosure and patching policies

By answering these questions and familiarizing yourself with the Kubernetes security response process, you can be an informed and confident user of open source software and ensure that your organization is taking an active role in your container security. For the latest in Kubernetes security news, be sure to subscribe to [email protected].

Introducing Workload Identity: Better authentication for your GKE applications

An application has needs. Maybe it needs to connect to a data warehouse, or connect to a machine learning training set. No matter what your application needs to do, there’s a good chance it needs to connect to other services to get it done. 

If that app runs on Kubernetes, this kind of authentication has traditionally been a challenge, requiring workarounds and suboptimal solutions. Which is why today we’re excited to announce Workload Identity, the new—and now recommended—way for GKE applications to authenticate to and consume other Google Cloud services. Currently in beta, Workload Identity works by creating a relationship between Kubernetes service accounts and Cloud IAM service accounts, so you can use Kubernetes-native concepts to define which workloads run as which identities, and permit your workloads to automatically access other Google Cloud services—all without having to manage Kubernetes secrets or IAM service account keys!

Authentication in GKE: an overview

To better understand Workload Identity, let’s look at your various authentication options for apps running on GKE. Before Workload Identity, there were two primary methods for authenticating GKE workloads to Google Cloud APIs: Storing service account keys as Kubernetes secrets, or using the node’s IAM service account. Both of these approaches have drawbacks in terms of ease of management and security.

Service account keys as secrets  
A Cloud IAM service account is an identity that an application can use to make requests to Google APIs. As an application developer, you could generate individual IAM service accounts for each application, and then download and store the keys as a Kubernetes secret that you manually rotate. Not only is this process burdensome, but service account keys only expire every 10 years (or until you manually rotate them). In the case of a breach or compromise, an unaccounted-for key could mean prolonged access for an attacker. This potential blind spot, plus the management overhead of key inventory and rotation, makes using service account keys as secrets a less than ideal method for authenticating GKE workloads. 

Node’s IAM service account
Since every GKE node is a Compute Engine instance, applications running on GKE inherit the properties of the underlying Compute Engine VM, including its IAM service account. You could give your pod access to this account, and use this to authenticate to other Google Cloud services. However, container architectures are dense by design—this means that when you’re running Kubernetes, you might want one pod to have privileged access to a service, but every other pod on the node should not. The principle of least privilege makes this method of authenticating GKE workloads less than ideal.

The new way: Workload Identity
That’s why we introduced Workload Identity, a new way to help reduce the potential “blast radius” of a breach or compromise and management overhead, while helping you enforce the principle of least privilege across your environment. It does so by automating best practices for workload authentication, removing the need for workarounds and making it easy to follow recommended security best practices. 

  • By enforcing the principle of least privilege, your workloads only have the minimum permissions needed to perform their function. Because you don’t grant broad permissions (like when using the node service account), you reduce the scope of a potential compromise.
  • Since Google manages the namespace service account credentials for you, the risk of accidental disclosure of credentials through human error is much lower. This also saves you the burden of manually rotating these credentials.
  • Credentials actually issued to the Workload Identity are only valid for a short time, unlike the 10-year lived service account keys, reducing the blast radius in the event of a compromise.

Workload Identity is project wide, so you can use it to grant permissions to new or existing clusters in your projects that share Kubernetes namespaces and Kubernetes service account names. For example, in the add-iam-policy-binding call below, any pod running under the Kubernetes namespace K8S_NAMESPACE and the Kubernetes service account KSA_NAME have permission to use the [GSA_NAME]@[PROJECT_NAME].iam.gserviceaccount.com IAM service account to access Google Cloud services.

Getting started with Workload Identity

After enabling Workload Identity on your cluster, configuring a Kubernetes service account to access Google Cloud services through Workload Identity is a simple, two step process.

When you enable Workload Identity on your cluster, your project receives an “Identity Namespace.” This is a new IAM primitive, used only for Workload Identity at this time. Workload Identity takes care of the intricacies of Identity Namespaces, though, so you don’t have to become an expert on it. (Although, if you’re interested in how Identity Namespaces works, check out our recent talk at Next ‘19.)

Here’s how to use Workload Identity: 1) grant the Kubernetes service account permission to use the targeted IAM service account. Here’s a sample command:

And then 2) update the IAM service account (referenced below as GSA_NAME) value for that Kubernetes namespace by using the `kubectl annotate` command. This lets the Kubernetes workload know which service account to use to access Google Cloud services. Anytime the workload uses the standard Google Client Libraries to access Google Cloud services, it will use that IAM service account.

GKE authentication done right

Most GKE applications are not islands—they interact with a wide variety of other Google Cloud services. Now, with Workload Identity, you have an authentication mechanism that is more secure, while being easy to set up, use and manage. To get started with Workload Identity, follow the steps we published in the documentation. It walks through enabling Workload Identity on a new cluster or steps to migrate an existing cluster. You can also check out a recent talk from Next ‘19 on workload identity to learn more.

Exploring container security: How DroneDeploy achieved ISO-27001 certification on GKE

Editor’s note: Aerial data mapping company DroneDeploy wanted to migrate its on-premises Kubernetes environment to Google Kubernetes Engine—but only if it would pass muster with auditors. Read on to learn how the firm leveraged GKE’s native security capabilities to smooth the path to ISO-27001 certification.

At DroneDeploy, we put a lot of effort into securing our customers’ data. We’ve always been proud of our internal security efforts, and receiving compliance certifications validates these efforts, helping us formalize our information security program, and keeping us accountable to a high standard. Recently, we achieved ISO-27001 certification— all from taking advantage of the existing security practices in Google Cloud and Google Kubernetes Engine (GKE). Here’s how we did it.

As a fast-paced, quickly growing B2B SaaS startup in San Francisco, our mission is to make aerial data accessible and productive for everyone. We do so by providing our users with image processing, automated mapping, 3D modeling, data sharing, and flight controls through iOS and Android applications. Our Enterprise Platform provides an admin console for role-based access and monitoring of flights, mapped routes, image capture, and sharing. We serve more than 4,000 customers across 180 countries in the construction, energy, insurance, and mining industries, and ingest more than 50 terabytes of image data from over 30,000 individual flights every month.

Many of our customers and prospects are large enterprises that have strict security expectations of their third-party service providers. In an era of increased regulation (such as Europe’s GDPR law) and data security concerns, the scrutiny on information security management has never been higher.. Compliance initiatives are one piece of the overall security strategy that help us communicate our commitment to securing customer data. At DroneDeploy, we chose to start our compliance story with ISO-27001, an international information security standard that is for recognized across a variety of industries.

DroneDeploy’s Architecture: Google Kubernetes Engine (GKE)

DroneDeploy was an early adopter of Kubernetes, and we have long since migrated all our workloads from virtual machines to containers orchestrated by Kubernetes. We currently run more than 150,000 Kubernetes jobs each month with run times ranging from a few minutes to a few days. Our tooling for managing clusters evolved over time, starting with hand-crafted bash and Ansible scripts, to the now ubiquitous (and fantastic) kops. About 18 months ago, we decided to re-evaluate our hosting strategy given the decreased costs of compute in the cloud. We knew that managing our own Kubernetes clusters was not a competitive advantage for our business and that we would rather spend our energy elsewhere if we could.

We investigated the managed Kubernetes offerings of the top cloud providers and did some technical due diligence before making our selection—comparing not only what was available at the time but also future roadmaps. We found that GKE had several key features that were missing in other providers such as robust Kubernetes-native autoscaling, a mature control plane, multi-availability zone masters, and extensive documentation. GKE’s ability to run on pre-emptible node pools for ephemeral workloads was also a huge plus.

Proving our commitment to security hardening

But if we were going to make the move, we needed to document our information security management policies and process and prove that we were following best practices for security hardening.

Specifically, when it comes to ISO-27001 certification, we needed to follow the general process:

  1. Document the processes you perform to achieve compliance
  2. Prove that the processes convincingly address the compliance objectives
  3. Provide evidence that you are following the process
  4. Document any deviations or exceptions

While Google Cloud offers hardening guidance for GKE and several GCP blogs to guide our approach, we still needed to prove that we had security best practices in place for our critical systems. With newer technologies, though, it can be difficult to provide clear evidence to an auditor that those best practices are in place; they often live in the form of blog posts by core contributors and community leaders versus official, documented best practices. Fortunately, standards have begun to emerge for Kubernetes. The Center for Internet Security (CIS) recently published an updated compliance benchmark for Kubernetes 1.11 that is quite comprehensive. You can even run automated checks against the CIS benchmark using the excellent open source project kube-bench. Ultimately though, it was the fact that Google manages the underlying GKE infrastructure that really helped speed up the certification process.  

Compliance with less pain thanks to GKE

As mentioned, one of the main reasons we switched from running Kubernetes in-house to GKE was to reduce our investment in manually maintaining and upgrading our Kubernetes clusters— including our compliance initiatives. GKE reduces the overall footprint that our team has to manage since Google itself manages and documents much of the underlying infrastructure. We’re now able to focus on improving and documenting the parts of our security procedures that are unique to our company and industry, rather than having to meticulously document the foundational technologies of our infrastructure.

For Kubernetes, here’s a snippet of how we documented our infrastructure using the four steps described above:

  1. We implemented security best practices within our Kubernetes clusters by ensuring all of them are benchmarked using the Kubernetes CIS guide. We use kube-bench for this process, which we run on our clusters once every quarter.
  2. A well respected third-party authority publishes this benchmark, which confirms that our process addresses best practices for using Kubernetes securely.
  3. We provided documentation that we assessed our Kubernetes clusters against the benchmark, including the tickets to track the tasks.
  4. We provided the results of our assessment and documented any policy exceptions and proof that we evaluated those exceptions against our risk management methodology.

Similarly to the physical security sections of the ISO-27001 standard, the CIS benchmark has large sections dedicated to security settings for Kubernetes masters and nodes. Because we run on GKE, Google handled 95 of the 104 line items in the benchmark applicable to our infrastructure. For those items that could not be assessed against the benchmark (because GKE does not expose the masters), we provided links to Google’s security documentation on those features (see Cluster Trust and Control Plane Security). Some examples include:

Beyond GKE, we were also able to take advantage of many other Google Cloud services that made it easier for us to secure our cloud footprint (although the shared responsibility model for security means we can’t rely on Google Cloud alone):

  • For OS level security best practices, we we able to document strong security best practices for our OS security because we use Google’s Container-Optimized OS (COS), which provides many security best practices by default by using things such as a read-only file system. All that was left for us to do was was follow best practices to help secure our workloads.
  • We use node auto-upgrade on our GKE nodes to handle patch management at the OS layer for our nodes. For the level of effort, we found that node auto-upgrade provides a good middle ground patching and stability. To date, we have not had any issues with our software as a result of node auto-upgrade.
  • We use Container Analysis (which is built into Google Container Registry) to scan for known vulnerabilities in our Docker images.
  • ISO-27001 requires that you demonstrate the physical security of your network infrastructure. Because we run our entire infrastructure in the cloud, we were able to directly rely on Google Cloud’s physical and network security for portions of the certification (Google Cloud is ISO-27001 certified amongst other certifications).

DroneDeploy is dedicated to giving our customers access to aerial imaging and mapping technologies quickly and easily. We handles vast amounts of sensitive information on behalf of our customers, and we want them to know that we are following best security practices even when the underlying technology gets complicated, like in the case of Kubernetes. For DroneDeploy, switching to GKE and Google Cloud has helped us reduce our operational overhead and increased the velocity with which we achieve key compliance certifications. To learn more about DroneDeploy, and our experience using Google Cloud and GKE, feel free to reach out to us.