Install SLS with CRI-O and containerd

You can run Sophos Linux Sensor (SLS) on a host with CRI-O or containerd installed. This applies whether you deploy SLS as a container image or install it as a host process via rpm or deb packages.

Configuration

The CRI configuration values are in the SLS configuration file, /etc/sophos/runtimedetections.yaml.

There are three CRI-specific configuration values:

You must prefix the addr value with unix:// or you'll see an error message. For example, if you want to connect to the CRI-O unix socket, you must enter addr as addr: unix:///var/run/crio/crio.sock.

Here's an example:

crisensor:
    enabled: true
    addr: unix:///var/run/crio/crio.sock
    poll_interval: 150ms

Default UNIX socket paths for supported runtimes

You can see the default paths for supported runtimes in the following table:

Container deployment

If you deploy SLS in a container, the path specified in crisensor.addr must match the path of the UNIX socket as mounted into the container.

If you're using CRI-O as your container runtime, you must set the environment variable GRPC_GO_REQUIRE_HANDSHAKE to off when running SLS. You can add this to the env section of your Kubernetes DaemonSet manifests.

Here's an example:

env:
 - name: GRPC_GO_REQUIRE_HANDSHAKE
   value: "off"

SLS requires this environment variable due to a GRPC protocol change starting in version 1.17. Many versions of CRI-O are built with the older version of GRPC and require the environment variable for compatibility.

If you don't set the GRPC_GO_REQUIRE_HANDSHAKE environment variable, you may see the following error message if SLS isn't able to connect to the CRI socket:

ERRO[0004] crisensor: connection error context deadline exceeded 

This error message indicates that SLS couldn’t connect to the CRI-compatible container runtime's UNIX socket. Setting the GRPC_GO_REQUIRE_HANDSHAKE environment variable solves the issue.

Event reorder window

Events aren't sent to the Sensor as they happen, so SLS must request them. This is due to the limitations of the CRI API. As of 2019-08-30, the API doesn't provide any mechanisms to notify a caller when a status change occurs. As a result, container events or status changes may occur between requests.

To work around this limitation, SLS issues synthetic events when it notices that it has missed a status change. For example, if a container has exited and isn't present at the next poll, SLS will forge a container exit event and a container destroyed event. You can resolve this issue by setting the event_reorder_window value to a longer duration (default is 25 ms) in runtimedetections-rules.yaml.

Here's an example:

event_reorder_window: 270ms

This example shows an event_reorder_window of 270ms, which will improve the ability of the analytics engine to appropriately enrich events with correct container data. However, increasing the reorder window will also have the effect of making response actions slower.