Install Sophos Linux Sensor on Kubernetes

Sophos Linux Sensor (SLS) is a lightweight agent installed on Linux hosts, collecting events from the hosts to trigger alert generation or automated response. SLS integrates with your existing logging and alerting infrastructure. You can deploy SLS wherever you have Linux, in a public or private cloud, containers or VMs, on-premises bare metal, and across different kernel versions and Linux distributions.

Note

We strongly recommend using Helm charts to deploy SLS. For details about deploying SLS using Helm charts, see Install Sophos Linux Sensor on Kubernetes using Helm Charts.

Requirements

We recommend that you have a good understanding of Kubernetes, Docker, and command-line tools such as kubectl before following this guide.
You must have kubectl version 1.18 or later. See Kubernetes Install Tools.
Get {LINUX_REPO_API_KEY} and {TENANT-ID} by following How to generate the Sophos Linux Sensor package registry API token.
- {LINUX_REPO_API_KEY} is a short string that starts with "SLS-".
- {TENANT-ID} is a string in the following format:
```
1a2345b6-78c9-012d-ef34-5a6b789c0de1
```
Get your Sophos Fusion MCS URL. See MCS URL.
Authenticate with the Helm registry by running the following command, replacing <LINUX_REPO_API_KEY> with your Sophos Linux registry API key:
```
helm registry login https://registry.sophosupd.com -u <LINUX_REPO_API_KEY> -p <LINUX_REPO_API_KEY>
```
Warning

You must authenticate to run the helm commands.
You must run the sensor in the root PID namespace. In most environments, kubelet and the node's container runtime run in the root PID namespace, so specifying hostPID: true is sufficient. In some non-production environments, for example, Minikube and kind, kubelet may run in a container instead of the root PID namespace.

Installation

These instructions are an example meant to provide an outline for deploying the sensor container image via Kubernetes. You can use the guidance here to customize your deployment using your tools of choice.

To install SLS on Kubernetes, do as follows:

Verify that kubectl is configured to point to your target installation cluster by running the following command:
```
kubectl config current-context
```
Set an environment variable in the terminal that you plan on using. Run the following command, replacing <TOKEN> with your Sophos package registry API key:
```
export SLS_TOKEN=$'<TOKEN>'
```
Create a new Kubernetes Secret. SLS uses this secret to authenticate your kubelet so that it can pull from our private container registry.
```
kubectl create secret docker-registry sophos-registry-secret --docker-server=registry.sophosupd.com --docker-username=$SLS_TOKEN --docker-password=$SLS_TOKEN
```
Run the following command to see your new secret:
```
kubectl get secrets
```
Note

Access is granted specifically for our manifest that references the K8's docker-registry sophos-registry-secret.
Create a file named values.yaml. The location doesn't matter.
Enter the following lines into the file, replacing <TENANT-ID> with your Sophos Fusion customer ID, <FUSION-URL> with your Sophos Fusion MCS URL, and <LINUX_REPO_API_KEY> with your Sophos Linux registry API key:
```
  sensor:
    params:
      customerID: <TENANT-ID>
      mcsURL: "<FUSION-URL>"
      mcsToken: "<LINUX_REPO_API_KEY>"
```
Tip

If you want to use a custom runtime detection profile, you must add it to values.yaml. See Add custom profiles from Sophos Fusion.
Save your changes

Run the following command to create a manifest named kubernetes-manifest.yaml:

helm template oci://registry.sophosupd.com/release/helm-sophos-linux-sensor -f values.yaml >> kubernetes-manifest.yaml

Tip

You can replace kubernetes-manifest.yaml with the name you want to give the file. We recommend that you use a name that identifies the SLS deployment, such as one that includes the SLS version or the runtimedetection profile.

This command generates a manifest file based on the most recent version of SLS. This file contains a ConfigMap and a DaemonSet for SLS. The configmap is mounted into /etc/sophos, containing the runtimedetections.yaml and runtimedetections-rules.yaml files. The DaemonSet creates one sensor pod per node.

Here's an example manifest file that includes all the Sophos Fusion data from values.yaml and custom content from a runtimedetections profile. Note that some values have been redacted.

Example

# This sensor does not communicate with a Console.

# Its alerts are only configured to go to stdout, and its configuration comes from Sophos content mounted into /var/lib/sophos/content

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: sophos-linux-sensor
  labels:
   app: sophos-linux-sensor
spec:
  selector:
    matchLabels:
     app: sophos-linux-sensor
  template:
    metadata:
      labels:
       app: sophos-linux-sensor
    spec:
      hostPID: true
      securityContext:
        runAsUser: 0
      imagePullSecrets:
      - name: sophos-registry-secret
      initContainers:
      - name: sophos-linux-content
        image: "registry.sophosupd.com/release/sophos-linux-content:5.19.6.1"
        volumeMounts:
          - mountPath: /var/lib/sophos/content
            name: sophos-linux-content
      containers:
      - name: sophos-linux-sensor
        image: "registry.sophosupd.com/release/sophos-linux-sensor:5.19.0.203"
        imagePullPolicy: IfNotPresent
        env:
        - name: RUNTIMEDETECTIONS_MONITOR_PORT
          value: "9010"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 9010
          failureThreshold: 10
        startupProbe:
          httpGet:
            path: /healthz
            port: 9010
          failureThreshold: 30
        resources:
          limits:
            memory: 2Gi
          requests:
            memory: 1Gi
        securityContext:
          privileged: true
          capabilities:
            add:
            - SYS_ADMIN
            - SETUID
            - SETGID
            - SETPCAP
            - SYS_PTRACE
            - KILL
            - DAC_OVERRIDE
            - IPC_LOCK
            - FOWNER
            - CHOWN
            - SYSLOG
            - NET_RAW
            - SYS_RESOURCE
        volumeMounts:
        - name: sensor-linux-sensor-config
          mountPath: /etc/sophos
        - name: sophos-linux-content
          mountPath: /var/lib/sophos/content
        - name: cgroup
          mountPath: /var/run/sophos/mnt/sys/fs/cgroup
          readOnly: true
        - name: debugfs
          mountPath: /var/run/sophos/mnt/sys/kernel/debug
        - name: hostname
          mountPath: /var/run/sophos/mnt/hostname
          readOnly: true
        - name: proc
          mountPath: /var/run/sophos/mnt/proc
          readOnly: true
        - name: var-lib-docker
          mountPath: /var/lib/docker
          readOnly: true
        - name: var-run-docker
          mountPath: /var/run/docker
          readOnly: true
        - name: var-run-containerd
          mountPath: /var/run/containerd
        - name: var-run-crio
          mountPath: /var/run/crio
      volumes:
      - name: sensor-linux-sensor-config
        configMap:
          name: sensor-linux-sensor-config
      - name: sophos-linux-content
        emptyDir: {}
      - name: cgroup
        hostPath:
          path: /sys/fs/cgroup
      - name: debugfs
        hostPath:
          path: /sys/kernel/debug
      - name: hostname
        hostPath:
          path: /etc/hostname
      - name: proc
        hostPath:
          path: /proc
      - name: var-lib-docker
        hostPath:
          path: /var/lib/docker
      - name: var-run-docker
        hostPath:
          path: /var/run/docker
      - name: var-run-containerd
        hostPath:
          path: /var/run/containerd
      - name: var-run-crio
        hostPath:
          path: /var/run/crio

---

apiVersion: v1
kind: ConfigMap
metadata:
  name: sensor-linux-sensor-config
data:
  runtimedetections-rules.yaml: |
    Chmod of SSH Authorized Keys:
      enabled: true
    Chown of SSH Authorized Keys:
      enabled: true
    Suspicious_Interactive_Shell-parentProgramName-allowList:
      operations:
        - behavior: remove
          list:
            - /usr/bin/sshd
            - /usr/sbin/sshd
    Suspicious_Interactive_Shell-parentProgramName-blockList:
      operations:
        - behavior: add
          list:
            - /bin/sh
  runtimedetections.yaml: |
    send_labs_telemetry: true
    endpoint_telemetry_enabled: true
    customer_id: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
    cloud_meta: auto
    crisensor.enabled: true
    mcs:
      url: "mcs2-cloudstation-us-west-2.prod.hydra.sophos.com"
      token: "SLS-XXXXXXXXXXXXXXXXXX"
    alert_output:
      outputs:
        - type: stdout
          enabled: true
          template: 'Alert Triggered: {{ .StrategyName}}'
        - type: mcs
          message_types: ["alert","smart_policy","audit"]
          enabled: true

Apply the manifest file, replacing <filepath> with the path to the location of the manifest file.
```
kubectl apply -f <filepath>/kubernetes-manifest.yaml
```
Wait for the pods to start, and then run the following command:
```
kubectl get pods -l app=sophos-linux-sensor
```
This command returns all pods with the label app=sophos-linux-sensor. You will need the name of the pods to confirm sensor functionality.

Tip

If you don't see SLS pods starting up, check your cluster's pod security policy and, if necessary, grant exceptions for the capabilities required by SLS. For a full list of these capabilities, please see the DaemonSet or contact Sophos support.

Confirm sensor functionality

You must replace <SENSOR_POD_NAME> in the following commands with the name of a sensor from the kubectl get pods -l app=sophos-linux-sensor command.

The logs for the sensor pods list all the configured policies:

kubectl logs <SENSOR_POD_NAME>

To generate a quick test alert, exec into one of the sensor pods:

kubectl exec -it <SENSOR_POD_NAME> -- /sophoslinuxsensor -test-alert

By default, SLS is configured to print alerts out to standard out, which can be seen if you view the logs from the pod that generated the alert by running the following command on the host:

kubectl logs <SENSOR_POD_NAME>

Alerts can also be sent out to webhooks, written directly to cloud blob storage buckets, written to local files on the file system with log rotation, and sent to syslog.

Check SLS versions

Because the manifest file you create is based on a specific version of SLS, you may want to update your manifest file when Sophos updates SLS. You can use the following curl commands to list the available tags for the SLS and default content images. Run the following commands:

curl -u {LINUX_REPO_API_KEY}:{LINUX_REPO_API_KEY} -X GET https://registry.sophosupd.com/v2/release/sophos-linux-sensor/tags/list |jq '.tags'

curl -u {LINUX_REPO_API_KEY}:{LINUX_REPO_API_KEY} -X GET https://registry.sophosupd.com/v2/release/sophos-linux-content/tags/list |jq '.tags'

These commands return the version tags for both sophos-linux-sensor and sophos-linux-content. From these tags, you can determine the version of SLS that you want to use for your manifest, whether it's the most recent version, or a previous version that suits your environment.

You can also find the latest version and tags in the Release notes. See Release notes.