Container plugin: can't use only containerd engine without enabling cri

[wangwillian0]

The following configuration doesn't work as expected. I need to enable the cri engine with the containerd at the same time, even though the crio.sock is not mounted.

As experiment, enabling only the cri engine and disabling the containerd doesn't work.

  - init_config:
      engines:
        bpm:
          enabled: false
        containerd:
          enabled: true
          sockets:
            - /run/containerd/containerd.sock
        cri:
          enabled: false
          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]

What do you mean with 👇 ?

even though the crio.sock is not mounted.

[wangwillian0]

I mean that cri-o is not used at all, so the socket isn't there.

[FedeDP]

Yep that's because most probably our matchers (that are exactly the same we had in libs), match the cgroups through the cri logic; but if you disable CRI, the cri matcher gets disabled too, thus while we receive containerd containers, we are not able to extract the container_id key from the cgroups and thus match them.

[FedeDP]

One possible workaround would be to always enable all matchers, and just disable the go-worker logic. This way we would always match container_id for all container engines, but we would only enrich with other metadata for enabled ones.

[leogr]

x-posting https://github.com/falcosecurity/plugins/pull/1004#issuecomment-3370872331

https://github.com/falcosecurity/charts/pull/892/files#diff-ef3f1a0c0800c919d45ffa98656d27cee2803963e4e13622ac22a08ce6548f0cR418-R424

The rationale is that containerd has no concept of a name for containers. Also, it usually exposes two sockets: one using the containerd protocol and another using the CRI protocol. Since CRI supports having a name for containers, the solution is to use CRI to consume /run/containerd/containerd.sock.