alcide

Alcide Blog

Cloud-native Security Provider

Cloud Native Security for Kubernetes In Practice

Oct 15, 2020 9:54:28 AM / by Alon Berger

The month of October is well recognized as the National Cyber Security Awareness Month.
Here at Alcide, we leverage the hype around Cyber Security and share our take on how to protect your Cyberspace, specifically with Kubernetes.

Recently, Alcide joined the Microsoft Intelligent Security Association (MISA), a growing ecosystem of independent software vendors, providing better solutions for increasing threats.
The timing couldn’t be better, as during this month of cybersecurity awareness we are reviewing Microsoft’s threat matrix for Kubernetes, based on the MITRE ATT&CK framework.

We will go through the various techniques in an upcoming blog series, covering all there is to know about the threat vectors.

But first, we begin with a much wider perspective.
Securing Cloud-Native Applications is a multi-objective and multi-constrained problem, spanning across individuals, teams, processes, culture, infrastructure, and tools. It is safe to assert that with cloud-native applications, nearly everything falls into security; from identity, through runtime and networking, handling data in flight, and everything in between.

In the recent KubeVirtual event, Alcide’s CTO and Co-founder, Gadi Naor shared his take on Kubernetes security for cloud-native applications. You can watch the full session here.

The Cloud Native Building Blocks

When thinking about Cloud Native security, we usually tend to break this down into two main components:

  1. Runtime environment - Here is where you make sure that everything works and operates as expected. It’s a matter of operational choice whether using self-hosted k8s clusters or fully managed Kubernetes services (EKS, GKE, AKS, ...) or on-prem.
  2. Supply chain management - Before landing workloads in production clusters, this is where a lot of the motion is happening. In these domains, developers build application components, configuration files, CI pipelines, container images and artifacts.

 

The Attacker Mindset and Frameworks

Let’s take a step back and review how the common attacker thinks.This would reveal two popular frameworks in the cybersecurity world: MITRE ATT&CK and Cyber kill chain.

  1. The MITRE ATT&CK framework is a knowledge base of known tactics and techniques that are involved in the cybersecurity world. This framework covers various stages that are involved in cyberattacks (tactics) and elaborate the known methods in each one of them (techniques). While mapping the security landscape of Kubernetes, Microsoft’s Azure Security Center noticed that there are similarities among the techniques and tactics. Therefore, we have been introduced to the first Kubernetes attack matrix: an ATT&CK-like mapping comprising the major aspects that are relevant to container orchestration security, with focus on Kubernetes.

  2. The Cyber kill chain model describes a series of steps required for an attacker to gain access to sensitive data and assets. From the early reconnaissance stages to the exfiltration of data, this model helps organizations to have a better understanding on how to identify and defend against attackers.


In general, both systems follow the same pattern – get in, don’t get caught, steal some stuff.

The primary difference between the two is that the ATT&CK matrix is more a list of techniques and tactics and doesn’t propose a specific order of operations, while The Cyber Kill Chain is a well-defined sequence of events.

When building Kubernetes security practices, one must think from a practical perspective how an attacker would try to seize exposed assets, what are the first tiers of attacks, and how to build effective defenses around those understandings.

 

Targeting Kubernetes-Based Applications

To better understand the moving parts inside Kubernetes and how an attacker would use it, we came up with the following diagram:


At the bottom left we have the Container Image Registry. This is an extremely important asset and an integral part of the supply chain framework, as it is essentially the source of whatever is going to land in your environment. As the defenders, our goal is to make sure that we can well guard our supply chain, securing CI systems and development cycles.

The control plane at the top represents the brain of the cluster, managing the worker nodes and the Pods in the cluster. In most cases, this component is something an attacker would have to go through when trying to perform any activity against the Kubernetes API server. Doing so may and probably will leave some traces

The worker nodes and their components essentially provide the runtime environment.
Every worker node runs Kubernetes components like kubelet, kube-proxy, container runtime, and application workloads, which can be considered as “system containers”, helping with build monitoring and logging infrastructure as an integral part of the environment.

 

Recent Kubernetes CVEs

While Kubernetes drastically simplifies the orchestration of your most sensitive containerized environments, it’s not bulletproof to critical security vulnerabilities that require quick detection and response. Such exploits became more frequent, coming in hot with every new version being released.

When reviewing recent vulnerabilities, we usually see two main areas - the control plane, and the worker nodes. For the control plane, on most cases, the severity of the CVE is relatively high. The most recent one (CVE-2020-14386), comes from a Linux kernel exploit that enables an attacker to perform privilege escalation through unsecured processes, representing a Container Escape - a doomsday scenario when it comes to container-based applications and infrastructure.

 

Alcide’s MITRE ATT&CK Matrix for Kubernetes

As mentioned earlier, this matrix lists for each stage of an attack the different techniques that are applicable specifically for Kubernetes, giving cloud-native application builders the ability to decide on which areas they should focus the most.

Let’s take a closer view at the Linux kernel vulnerability and see how it looks on the matrix itself:

 

We can see that in order to exploit or leverage the Linux kernel vulnerability, the attacker needs to have an initial access to a container that is running with the relevant privileges, and being able to run the exploit from this specific container. This leads to performing privilege escalation to the node, allowing exploitation via other CVEs related to the node, ultimately resulting in lateral movement, maneuvering from one Kubernetes asset to another.

 

Kubernetes Security Recipe for Day 2

Like any other infrastructure platform, building a tactical approach based on Kubernetes security best practices is key when maintaining secure deployments and workloads.

Here’s our take on formulating a plan for hardening the security guardrails for your Kubernetes environment:

  1. Establish Security Foundations:

    1. Identity & Access management - Implement authentication strategies like client certificates, bearer tokens, authentication proxy or a basic HTTP request authentication.

    2. Supply chain - Using immutable artifacts, trusted image sources and private image registries.

    3. Secrets management - Secrets by themselves have a life span beyond a single cluster. While Kubernetes provides some basic management capabilities, there are several common risks that require broader enforcement. Consider using tools like Vault and AWS Key Management Service (KMS).

  2. Incremental Attack Surface Coverage:

    1. Reduce privileges - By using Role-based access control (RBAC) and tuning the Kubernetes configuration files, limit access and permission for containers and pods across the CI\CD pipeline. For example, preventing containers from running as root.

    2. Kubernetes Infrastructure patch/upgrade playbook - If you are on some sort of managed Kubernetes services, those providers will take care of such upgrades. However, if you are self-managed, you need to have strict guidelines and well established operation practices in order to stay up to date with new CVEs.

    3. Security monitoring and enforcement - Make sure you cover the relevant areas of concern in the Kubernetes infrastructure. For example - monitor network access to the API server, nodes, etcd and fire alerts when detecting such movement. Using AI-driven analysis tools is highly recommended here.

  3. People - security is everybody’s job, but…

    1. Avoid controls/practices that create alert/findings fatigue.

    2. Match security controls to align with team skills and capabilities.

    3. Manage incident and response workflows with security program tool stack.

  4. Automation

    Using multi-cluster and multi-cloud enablers to make your life easier when implementing automation in Dev, CI\CD and runtime environments.

 

Conclusion

In this article we covered the fundamentals aspects of Kubernetes security, when running cloud-native applications, with a brief introduction to the Kubernetes threat matrix and recent CVEs.

In the upcoming posts, we will go over the different vectors and review their techniques and tactics, and most importantly, how to defend against them.

 

Topics: cloud security, kubernetes, Kubernetes security

Subscribe to Email Updates