Kubernetes Runtime Protection

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

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.

echo -n 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > eicar
chmod +x eicar
./eicar

The Profiling engine works in two phases:

1. Profile Learning

2. 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:

1. Open a container with enabled Runtime Protection (see Enabling Runtime Protection on a Cluster).

2. In the Protected Assets tab, expand the Kubernetes Deployment group.

3. Find the deployment that contains runtime-policy in its name and click it.

4. 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.

During the learning process, the Runtime Protection tab shows the current profiling status:

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 from the profile, and CloudGuard cannot complete it during the profiling period. The profiling status appears as Partial. To consider a profile complete, two conditions are necessary:

• CloudGuard detects a pod The smallest and simplest Kubernetes object. A pod represents a set of running containers on your cluster. A pod is typically set up to run a single primary container. It can also run optional sidecar containers that add supplementary features like logging. Pods are commonly managed by a Deployment. startup event

• The profile period is completed.

A Partial profile is enforced and can become Completed once the startup event is detected. 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.

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.