The Rise of Kubernetes: In the past three years there has been a massive growth in the adoption of container technology. A major driver of this growth is the emergence of Kubernetes as the de-facto standard for orchestration of containerized workloads, displacing Mesos Marathon, Docker Swarm and even Pivotal’s Cloud Foundry.

Kubernetes in 2019 is a defining attribute of what it is to be cloud native.

Kubernetes not only schedules containers to run in a cluster of worker nodes, it also handles storage and network provisioning, secrets management and much more. It is a powerful extensible platform for running many complex applications with a combination of stateful and stateless components.

Shared Responsibility

Security for Kubernetes, as with any platform, is divided into several layers: security of the platform itself, security of the configuration of assets provisioned by the platform and security of the application running on the platform.

Security of Kubernetes as a platform has been a focus area for the cloud native community in the last couple of years, starting from encryption of secrets, making Role-Based Access Control (RBAC) manageable and supporting encryption of all control plane traffic.  A full third-party security audit of Kubernetes was published in May, further validated the security of the platform.

What’s left for users of the Kubernetes platform is the responsibility for securing their applications’ configuration and code as well as implementing runtime security procedures. It’s all part of a broader concept generally known as shared responsibility. Just because Kubernetes as a platform has security capabilities, does not mean that applications that run on Kubernetes are secured.

There have been multiple studies in recent years that have consistently shown that not all Kubernetes users are actually taking steps to make sure their cloud native applications are secured. Not securing Kubernetes comes with real world consequences, including the risk of a data breach.

Securing Applications in Kubernetes

So what should users do to secure Kubernetes?

Among the first steps that many organizations take is to statically scan the container images before they are deployed for potential risks.  While scanning can identify some risks, including identifying known vulnerabilities in the software packages that are installed in those images, scanning alone is not sufficient to secure Kubernetes applications.

Among the limitations of a scanning-only approach:

• Zero day vulnerabilities – Scanning covers known vulnerabilities. It does not provide any means to detect and stop an attack that is taking advantage of new vulnerabilities or security holes in the application logic itself.
• Limited remediation – Not all vulnerabilities reported by a scanner have an available fix and there is often a need for additional control measures such as network segmentation and privilege management.
• Limited scope – In addition to running containers, Kubernetes manages many kinds or resources. Relying on static image scans leaves the ops and security teams blind to any and all misconfigurations, some very common, of those resources.

Look Beyond Scanning for Kubernetes Security

A complete solution for Kubernetes security starts by augmenting scanning with additional controls in the CI/CD process that examine all the resources that are deployed into a cluster. Such controls create guardrails which allow developers to maintain agility without compromising security by introducing unnecessary and unacceptable risks.

Securing the development and CI/CD process is meant to reduce and control the risk of exposure in the production environment. It never fully eliminates the potential for an attack, either coming from an external attacker or an internal one. Runtime security has to be put in place both to detect intrusion and to provide an audit trail for all operations and changes in that environment.

Applying a Zero Trust approach is also key to reducing risk. The basic idea behind zero trust is that there is no perimeter and all traffic should be encrypted and authenticated. Layering zero trust on top of security policy controls can further help to reduce risk in a way that simply scanning container images can not do.

One of the emerging approaches to help secure cloud native deployments is with the use of a service mesh. A service mesh adds a proxy alongside the workload to offload common layer-7 network functions such as timeouts, retries and load balancing. Having a common, distributed component which routes all the cluster’s traffic is the most logical place to implement security features such as encryption, authentication, segmentation, access control and threat detection. The telemetry gathered by all those proxies can also be used to profile the behavior of workloads and implement policy automation and anomaly detection.

Kubernetes Security Shouldn’t be a Blind Spot

If all you do is scan container images for known vulnerabilities, there is a very large security blind spot in your organization’s risk posture.

While running container images with known vulnerabilities is obviously not a best practise for any organization, misconfigured clusters, insider and outsider threats are all additional attack vectors that could be putting a Kubernetes deployment at risk.

A security strategy for containerized workloads that relies solely on container image scanning isn’t a much of a strategy.

What is needed is a suite of tools that cover the entire application lifecycle from development through CI/CD phase and runtime. Cloud native Kubernetes deployments introduce new opportunity as well as new complexity. Cloud native also can be the driver of organizational and cultural changes that put a lot more power over infrastructure into the hands of the developers and places the responsibility to secure those environments on the DevOps team.

The tools that make up your cloud native security suite have to be designed to address the technical challenges, while embracing this new culture.

To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon NA, November 18-21 in San Diego.

Haim Helman is CTO and co-founder of Octarine, a continuous network security platform for Kubernetes. He has been leading enterprise infrastructure innovation for the last 20 years. Before Octarine, he co-founded XIV, an enterprise storage company which was acquired by IBM. Following his time at IBM he was a member of the founding team at Robin Systems, where he first encountered the promise and challenges of cloud-native architecture. He holds a BSc in Math, Physics and Computer Science from the Hebrew University in Jerusalem and an MSc in Computer Science from Tel Aviv University.