Is it working with aws bottlerocket OS

[NaomiLYJ]

We were working on Amazon linux2 with the rpm installation and would like to switch to bottlerocket.

It is said in the official documentation that falcon-sensor on Bottlerocket is supported, but I could not find a way how to do that.

And I came across this container solution, but not sure if it's compatible with the bottlerocket. Could someone help answer here?

[redhatrises]

@NaomiLYJ yes, Bottlerocket is supported. When deploying with helm, you will need to configure and run in BPF mode while using the official daemonset images.

[NaomiLYJ]

Thank you so much for your reply! Do you happen to know if it's possible to run falcon-sensor in a host container of the Bottlerocket, or the k8s daemonset is the best or only solution to run falcon-sensor on bottlerocket?

[redhatrises]

You will need to use the k8s daemonset image that CrowdStrike provides.

[NaomiLYJ]

Thank you again for your reply! Do you know any reference documentation how to do that?

I see that in the daemonset there is init container doing some stuff, but as far as I know, sidecar container could not be configured in host container on bottlerocket. Besides there is volume mount to the host path. So the setup could be different.

[redhatrises]

You can use helm to configure the falcon-sensor daemonset (falcon-linux image) to be deployed to the bottlerocket nodes. You definitely should not use the sidecar sensor (falcon-container image).

[NaomiLYJ]

Hi @redhatrises , maybe we misunderstood each other. Instead of running falcon-sensor as daemonset managed by k8s, could we just run the falcon-sensor directly to each bottlerocket node, i.e., not managed by the k8s, but by the host container runtime like containerd.

I know this could be difficult, as normally host container runtime does not support init-containers like in daemonset:

initContainers:
      # This init container creates empty falconstore file so that when
      # it's mounted into the sensor-node-container, k8s would just use it
      # rather than creating a directory.  Mounting falconstore file as
      # a file volume ensures that AID is preserved across container
      # restarts.  Sensor versions 6.54+ have a helper binary to initialize falconstore.
      - name: init-falconstore
        image: "{{ include "falcon-sensor.image" . }}"
        imagePullPolicy: "{{ .Values.node.image.pullPolicy }}"
        command:
          - /bin/bash
        args:
          - '-c'
          - >-
            echo "Running /opt/CrowdStrike/falcon-daemonset-init -i";
            /opt/CrowdStrike/falcon-daemonset-init -i
        {{- if or .Values.node.gke.autopilot .Values.node.daemonset.resources }}
        resources:
          requests:
            cpu: 10m
            ephemeral-storage: 100Mi
            memory: 50Mi
          limits:
            cpu: 10m
            ephemeral-storage: 100Mi
            memory: 50Mi
        {{- end }}
        securityContext:
          runAsUser: 0
          privileged: true
          allowPrivilegeEscalation: true
        {{- if .Values.node.gke.autopilot }}
          readOnlyRootFilesystem: true
          capabilities:
            add:
              - SYS_ADMIN
              - SYS_PTRACE
              - SYS_CHROOT
              - DAC_READ_SEARCH
        {{- else }}
          readOnlyRootFilesystem: false
        {{- end }}
      containers:
      - name: falcon-node-sensor
        image: "{{ include "falcon-sensor.image" . }}"
        imagePullPolicy: "{{ .Values.node.image.pullPolicy }}"
        # Various pod security context settings. Bear in mind that many of these have an impact
        # on the Falcon Sensor working correctly.
        #
        # - User that the container will execute as. Typically necessary to run as root (0).
        # - Runs the Falcon Sensor containers as privileged containers. This is required when
        #   running the Falcon Linux Sensor on Kubernetes nodes to properly run in the node's
        #   kernel and to actually protect the node.
        securityContext:
          runAsUser: 0
          privileged: true
          readOnlyRootFilesystem: false
          allowPrivilegeEscalation: true
        {{- if .Values.node.gke.autopilot }}
          capabilities:
            add:
              - SYS_ADMIN
              - SETGID
              - SETUID
              - SYS_PTRACE
              - SYS_CHROOT
              - DAC_OVERRIDE
              - SETPCAP
              - DAC_READ_SEARCH
              - BPF
              - PERFMON
              - SYS_RESOURCE
              - NET_RAW
              - CHOWN
              - NET_ADMIN
        {{- end }}
        {{- if (eq .Values.node.backend "bpf") }}
        {{- include "falcon-sensor.daemonsetResources" . | nindent 8 }}
        {{- end }}
        envFrom:
        - configMapRef:
            name: {{ include "falcon-sensor.fullname" . }}-config
        volumeMounts:
          - name: falconstore
            mountPath: /opt/CrowdStrike/falconstore
      volumes:
        - name: falconstore
          hostPath:
            path: /opt/CrowdStrike/falconstore
      serviceAccountName: {{ .Values.serviceAccount.name }}

But this could be achievable if we knew what the init-container does that we could prepare in advance before starting the falcon-sensor container on the host. Thank you very much for your help!