Kubernetes Runtime Protection
Kubernetes 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 |
|
|
CentOS / RHEL |
|
|
|
Linux kernel v4.14 and higher |
No installation required |
|
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
andread
permissions) and the Runtime Protection Daemon agents (read
permissions). Access to the CR, which includeread
permissions likeget
andlist
, 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:
-
Kubernetes Deployments
-
Kubernetes ReplicaSets
A ReplicaSet (aims to) maintain a set of replica Pods running at any given time., unless it is a dependent resource
-
Kubernetes Pods, unless it is a dependent resource
|
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.
![Closed](transparent.gif)
The Signatures engine monitors the workloads' system calls and compares them to a predefined set of signatures corresponding to potentially malicious behavior. It also prevents possible threats and when it finds a malicious signature, it kills the main process of the container. The Check Point research team dynamically updates the signatures in CloudGuard to address emerging threats and vulnerabilities.
Examples signatures:
-
Modification of
/etc/passwd
file -
Execution of a crypto miner binary
|
Note - For testing, it is possible to create a simulated signature event. For this, create an executable file named
|
![Closed](transparent.gif)
The File Reputation engine monitors real-time executables that run on the workload. With Check Point ThreatCloud solution, the engine detects and prevents the execution of malicious files.
|
Note - For testing, it is possible to create a simulated file reputation event. For this, execute the commands below with a Bash shell (for example, BusyBox) in one of the pods: Copy
After successful simulation, the prompt shows syntax error messages, for example:
|
![Closed](transparent.gif)
The Profiling engine works in two phases:
-
Profile Learning
-
Profile Enforcement
During the first phase, the Profiling engine learns the behavior patterns of the workloads that run in a given cluster and builds their profile. The profile (allowlist) is a policy that describes what this workload can do: which processes it can run and which domains it can access. When the learning is complete, the second phase begins. CloudGuard can detect violations and trigger alerts when one of the containers in a Pod Group performs an operation or accesses a network not observed during the profiling phase.
Profile Learning
For each node, the CloudGuard agent monitors the system calls that containers make in the node. When a new Pod Group is deployed in a cluster, CloudGuard monitors all the processes and network activity on all the Pod Groups until the profiling period ends. By default, the profiling period is 24 hours. It starts from the moment when the CloudGuard agent discovers a new Pod Group deployment or when Runtime Protection is enabled for existing Pod Groups. At the end of the period, the agent creates a security profile (baseline) of the Pod Group.
To see the learned profile:
-
Open a container with enabled Runtime Protection (see Enabling Runtime Protection on a Cluster).
-
In the Protected Assets tab, expand the Kubernetes Deployment group.
-
Find the deployment that contains runtime-policy in its name and click it.
-
The Runtime Protection tab contains the profile details in the Processes and Network sections. Each process and network learned at this stage has the Runtime tag in its line.
-
Processes - CloudGuard designates each allowed process with a combination of the process path and the path of the Parent process (the one that initiated it). At the policy enforcement stage, CloudGuard does not allow a process if a different Parent process initiates it.
-
Network - A combination of the allowed network domain and the parent process.
|
Notes:
|
During the learning process, the Runtime Protection tab shows the current profiling status:
Status |
Description |
Profiling Period |
---|---|---|
In Progress (%) |
CloudGuard is learning the workload behavior. End Time indicates when the learning completes. |
Not finished |
Finalizing |
CloudGuard is creating the profile based on the collected data. |
On hold |
Wait For Startup |
On hold |
|
Completed |
CloudGuard has a full profile of the Pod group. |
Finished |
Disabled |
Runtime Protection is disabled. |
Not started |
The profile contains information on the workload life cycle from its deployment to the stage of stable running. If CloudGuard starts the profile learning after the workload has been deployed, its startup information is missing in the profile, and CloudGuard cannot complete it during the profiling period. The profiling status appears as Wait for Startup. Until the profile is complete, CloudGuard cannot enforce Runtime Protection.
To complete the profiling process, select one of two options below:
-
Wait until the workload life cycle spawns a new pod naturally.
-
Delete the pod.
|
Important - If you decide to delete a pod, do it with caution. This may have undesirable side effects on specific workloads, although it triggers the creation of a new pod. |
Profile Enforcement
When the profile is complete, the agent stops to collect events and starts to enforce protection. When one of the containers in the Pod Group does an operation not observed during the profiling phase, the engine detects a violation and triggers an alert.
CloudGuard associates a Pod Group profile with a version and identifies it as the combination of all the containers' images. When it detects a container update with a new image version (for example, with the same image but a new image tag), it resets the profile, and a new learning period begins. User-defined settings, such as signature exclusions, stay intact.
More Links