Container plugin: `container.liveness_probe` is always `NONE`

[wangwillian0]

The fields container.healthcheck, container.liveness_probe and container.readiness_probe are always NONE. In this case I created a rule that uses these fields in the output. The event type is filtered by evt.type in (execve, execveat).

I captured the process spawning for a few minutes, so it's not a delayed initialization or something like that.

pod:

apiVersion: v1
kind: Pod
metadata:
  name: debugging
spec:
  containers:
  - name: netshoot
    image: nicolaka/netshoot
    command: ["/bin/bash", "-c", "while true; do sleep 100; ls; done"]
    livenessProbe:
      exec:
        command:
        - "ls"
        - "-111"
      initialDelaySeconds: 5
      periodSeconds: 10
  - name: alpine
    command: ["/bin/sh", "-c", "while true; do sleep 100; ls; done"]
    image: alpine
  restartPolicy: Always

falco.yaml:

plugins:
  - init_config: ""
    library_path: libjson.so
    name: json
  - init_config:
      engines:
        bpm:
          enabled: false
        containerd:
          enabled: true
          sockets:
            - /run/containerd/containerd.sock
        cri:
          enabled: true # need to enable it too for some reason (maybe bug?)
          sockets:
            - /run/crio/crio.sock
        docker:
          enabled: false
          sockets:
            - /var/run/docker.sock
        libvirt_lxc:
          enabled: false
        lxc:
          enabled: false
        podman:
          enabled: false
          sockets:
            - /run/podman/podman.sock
      hooks:
        - create
      label_max_len: 100
      with_size: false
    library_path: libcontainer.so
    name: container

[leogr]

Plugin version?
Falco version?

[leogr]

Also re:

containerd:
enabled: true
sockets:
- /run/containerd/containerd.sock
cri:
enabled: true # need to enable it too for some reason (maybe bug?)
sockets:
- /run/crio/crio.sock

Both must be enabled, but the socket configurations are not correct. See #1004 (comment)

[deepskyblue86]

@wangwillian0 and container engine please

[leogr]

After a second look, I think the issue may be the same of container.name when the wrong engine configuration is provided.

Please try to use CRI to consume /run/containerd/containerd.sock as explained here #1004 (comment) 🙏

[wangwillian0]

@wangwillian0 and container engine please

Containerd, and I'm using the latest version of the container plugin.

[wangwillian0]

After a second look, I think the issue may be the same of container.name when the wrong engine configuration is provided.

Please try to use CRI to consume /run/containerd/containerd.sock as explained here #1004 (comment) 🙏

Tried it and the container.name is populated but the container probe fields are not.

Just for completeness, Im using falco 0.41.3, container plugin 0.3.7, in a containerd environment (i.e. mounting only /run/containerd/containerd.sock). I tried both using the container_engines from falco's builtin plugin and the init_config from the container plugin to configure it.

plugins:
  - init_config: ""
    library_path: libjson.so
    name: json
  - init_config:
      engines:
        bpm:
          enabled: false
        containerd:
          enabled: false
          sockets:
            - /run/containerd/containerd.sock
        cri:
          enabled: true
          sockets:
            - /run/containerd/containerd.sock
            - /run/crio/crio.sock
        docker:
          enabled: false
          sockets:
            - /var/run/docker.sock
        libvirt_lxc:
          enabled: false
        lxc:
          enabled: false
        podman:
          enabled: false
          sockets:
            - /run/podman/podman.sock
      hooks:
        - create
      label_max_len: 100
      with_size: false
    library_path: libcontainer.so
    name: container

[deepskyblue86]

@wangwillian0 would you be so kind to test that with falco 0.40.0, i.e. the last release before container plugin?

[wangwillian0]

@deepskyblue86 just tried it and it also spits "NONE" for every field

[deepskyblue86]

@deepskyblue86 just tried it and it also spits "NONE" for every field

From what I can read from libs code (0.18.x) those fields were implemented only for Docker engine (6 years ago, draios/sysdig@ed782e86).
I did a brief investigation on the CRI engine, and it should be fairly trivial to implement it there.

[deepskyblue86]

Leaving some notes here for myself

(dlv) p podSandboxStatus.Status.Annotations["kubectl.kubernetes.io/last-applied-configuration"]
"{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"annotations\":{},\"name\":\"debugging\",\"namespace\":\"default\"},\"spec\":{\"containers\":[{\"command\":[\"/bin/sh\",\"-c\",\"while true; do sleep 100; ls; done\"],\"image\":\"busybox:stable\",\"livenessProbe\":{\"exec\":{\"command\":[\"ls\",\"-111\"]},\"initialDelaySeconds\":5,\"periodSeconds\":10},\"name\":\"netshoot\"},{\"command\":[\"/bin/sh\",\"-c\",\"while true; do sleep 100; ls; done\"],\"image\":\"alpine\",\"name\":\"alpine\"}],\"restartPolicy\":\"Always\"}}\n"

https://github.com/falcosecurity/libs/blob/release/0.18.x/userspace/libsinsp/container_engine/docker/async_source.cpp#L40
https://github.com/falcosecurity/libs/blob/release/0.18.x/userspace/libsinsp/container_engine/docker/async_source.cpp#L264

[wangwillian0]

Btw, proc.is_container_healthcheck, proc.is_container_liveness_probe and proc.is_container_readiness_probe are fields that are also not working. They should be easier to derive by checking the proc.acmdline with the three container fields mentioned above, I think.