Kubernetes in the cloud — shared security responsibility

Just as with other compute resources, many organizations choose to run Kubernetes in the cloud. You have multiple options for how to run Kubernetes in the cloud:

  • self-managed Kubernetes
  • commercial distribution of Kubernetes
  • managed Kubernetes service

Whichever model you choose, you and the cloud provider “share” responsibility for securing the deployment. While the typical shared responsibility model applies, with Kubernetes - especially with managed Kubernetes services - where the line falls in terms of responsibility for security can sometimes feel confusing.

With managed Kubernetes services, the cloud provider manages the Kubernetes control plane - the services that run on master nodes. Services typically include setting up the master nodes, enabling redundancy of those nodes, often including running them in different regions to prevent an outage should part of the cloud provider’s infrastructure go down. Typically, the cloud providers:

  • Will keep Kubernetes up to date
  • Will keep master nodes patched
  • May provide patching of Node OS — often depends on your choice of OS, as in GKE’s support for Ubuntu vs COS
  • Will often offer container-optimized OS images for Nodes
  • Will sometimes include vulnerability scanners - but you must create the policy, such as using Admission Controller to allow/deny based on scanning results

The customer is always responsible for securing the Kubernetes workload, including these security aspects:

  • Container images — their source, contents, and vulnerabilities*
  • Deployments — network services, storage, privileges
  • Configuration management — roles, groups, role bindings, service accounts
  • Application — secrets management, labels, annotations
  • Network segmentation — network policies in the cluster
  • Runtime — threat detection and incident response

Commercial Kubernetes distributions — including Red Hat OpenShift, Rancher, Pivotal, and Mirantis/Docker Enterprise — introduce their own variances. These deployments are cloud agnostic and so can run anywhere. They’re designed to make it easy to deploy and scale Kubernetes clusters and provide integrated enterprise services.

For these distributions, keep the following security impacts in mind:

  • These platforms are focused on ease of management, not security, though they sometimes include security-related features, such as OpenShift enabling restrictions on image sources and runtime
  • Some platforms include vulnerability scanners but they typically provide minimal operational process
  • Some providers offer container-optimized Node OS, but the update process is your responsibility
  • These providers will distribute Kubernetes patches to remediate vulnerabilities, but typically the update process will be your responsibility
  • You will need to manage complementary infrastructure controls, which vary depending on the cloud provider or infrastructure

Last updated: May-30-2020