Kubernetes Runtime Protection

KubernetesClosed Kubernetes, often abbreviated as “K8s”, orchestrates containerized applications to run on a cluster of hosts. Runtime Protection allows CloudGuard to monitor containers in real time and prevent runtime threats that can compromise the user's live environment. The Runtime Protection mechanism combines several engines that monitor kernel system calls, file access, and network activity, and protects against possible security threats.

Prerequisites

Your Kubernetes cluster must already be onboarded to CloudGuard. See Onboarding Kubernetes Clusters for details on how to do this.

Runtime Protection Daemon requires the installation of Linux kernel headers on each node before the deployment.

To install the kernel headers, use the commands below:

Operating System

Supported Version

Command

Ubuntu / Debian

 

apt-get install -y linux-headers-$(uname -r)

CentOS / RHEL

 

yum -y install kernel-devel-$(uname -r)

Linux kernel v4.14 and higher

No installation required

  • AWS Bottlerocket (File Reputation)

Linux kernel v1.11.1 and lower

No installation required

For Kubernetes Runtime Protection minimum requirements, see Supported Versions.

How it Works

Architecture

Resources

Runtime Protection includes these resources:

  • Runtime Protection Policy Agent - A single-replica Deployment responsible to retrieve CloudGuard configuration and policies and keep them on the cluster.

  • Runtime Protection Daemon - A DaemonSet running the Runtime Protection engines that interact with the underlying node to monitor the container activity.

  • Custom Resource Definitions (CRD) - Kubernetes custom resources (CR) for Runtime Protection policies. The CRD is managed by the Runtime Protection Policy agent. The CR is only accessible to the Runtime Protection Policy agent (modify and read permissions) and the Runtime Protection Daemon agents (read permissions). Access to the CR, which include read permissions like get and list, should be restricted because it contains the cluster security configuration.

  • Inventory Agent - A single-replica Deployment responsible to report inventory information on the cluster resources to CloudGuard.

Pod Groups

Runtime Protection refers to all pods of the same owner as members of a Pod Group. The Pod Group is the basic entity to which the Runtime Policy applies. The relationship between dependent resources appears in the ownerReferences property of all workload resources. A Pod without an owner is called an Independent Pod. An Independent Pod is considered its own Pod Group. In general, each entity in an environment can be considered a member of the Pod Group represented by the highest root entity above it.

All Runtime Protection rules, exclusions, and profiles that are managed on the Pod Group apply to all the pods in the group. For example, a new rule created in the context of a deployment Pod Group applies to all pods within this deployment.

Independent pods that you explicitly provision differ from the pods that a Kubernetes controller creates as part of the life cycle of another (parent) resource (a Pod Group).

Independent Pod Groups are:

Note - Pods derived from other controllers, such as Jobs, are considered independent.

Signatures, File Reputation, and Profiling

Kubernetes Runtime Protection has three primary engines:

  • Signatures (Limited General Availability) - Compares the observed behavior of a workload with known signatures that potentially show malicious behavior. For example, the execution of processes related to crypto-mining software.

  • File Reputation (Limited General Availability) - Detects in real time malicious access to executable files with Check Point Reputation Service.

  • Profiling (Public Preview) - Detects anomalies in behavior compared to a baseline profile created during a profiling phase.

Signatures and File Reputation are enabled by default for all Pod Groups.

More Links