Container enrichment fails for plain Docker on Tetragon v1.5.0

[rnosal]

What happened? How can we reproduce this?

Hi. I am experiencing an issue where container metadata (name, ID) is not being added to events for processes running in standard Docker containers on a non-Kubernetes system.

I installed Tetragon v1.5.0 on Ubuntu 24.04.2 LTS.

Configuration:

1. Policy to capture tcp connection:

# cat tetragon.tp.d/monitor-ports.yaml 
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "monitor-connections"
spec:
  kprobes:
  - call: "tcp_connect"
    syscall: false
    args:
    - index: 0
      type: "sock"
    selectors:
    - matchArgs:
      - index: 0
        operator: "NotDAddr"
        values:
        - "127.0.0.1/8"
        - "172.16.0.0/12"
        - "192.168.0.0/16"

2. Additional Daemon configuration needed to turn on enrichment layer:

# cat cri-endpoint
unix:///run/containerd/containerd.sock
# cat enable-cri
true
# cat enable-pod-annotations
true
# cat enable-pod-info
true
# cat enable-cgidmap
true

3. Changed conteinerd config which by default has cri plugin disabled:

# disabled_plugins = ["cri"]

4. crictl shows correct output:

crictl info | grep -a8 status
{
  "status": {
    "conditions": [
      {
        "type": "RuntimeReady",
        "status": true,
        "reason": "",
        "message": ""
      },
      {
        "type": "NetworkReady",
        "status": false,
        "reason": "NetworkPluginNotReady",
        "message": "Network plugin returns error: cni plugin not initialized"
      },
      {
        "type": "ContainerdHasNoDeprecationWarnings",
        "status": true,
        "reason": "",
        "message": ""
      }
    ]
  },

How to reproduce:

1. Run simple curl inside docker container and capture logs. Process and its network connections are captured successfully, but they are not enriched with any container information.

{
  "process_kprobe": {
    "process": {
      "exec_id": "cm9rLTIwLTE6MjU4ODA1NTAyMjk1OTI5OjEyNzcxNjM=",
      "pid": 1277163,
      "uid": 0,
      "cwd": "/",
      "binary": "/usr/bin/curl",
      "arguments": "google.com",
      "flags": "execve rootcwd clone inInitTree",
      "start_time": "2025-08-21T10:24:17.249602759Z",
      "auid": 4294967295,
      "parent_exec_id": "cm9rLTIwLTE6MjU4Nzk3NjE4MDg4NzQ0OjEyNzcxMjA=",
      "refcnt": 1,
      "tid": 1277163,
      "in_init_tree": true
    },
    "parent": {
      "exec_id": "cm9rLTIwLTE6MjU4Nzk3NjE4MDg4NzQ0OjEyNzcxMjA=",
      "pid": 1277120,
      "uid": 0,
      "cwd": "/",
      "binary": "/bin/sh",
      "flags": "execve rootcwd clone inInitTree",
      "start_time": "2025-08-21T10:24:09.365392801Z",
      "auid": 4294967295,
      "parent_exec_id": "cm9rLTIwLTE6MjU4Nzk3NTQwNDk5Nzc3OjEyNzcwOTY=",
      "tid": 1277120,
      "in_init_tree": true
    },
    "function_name": "tcp_connect",
    "args": [
      {
        "sock_arg": {
          "family": "AF_INET",
          "type": "SOCK_STREAM",
          "protocol": "IPPROTO_TCP",
          "saddr": "172.17.0.2",
          "daddr": "216.58.204.238",
          "sport": 40616,
          "dport": 80,
          "cookie": "18446624423516937152",
          "state": "TCP_SYN_SENT"
        }
      }
    ],
    "action": "KPROBE_ACTION_POST",
    "policy_name": "monitor-connections",
    "return_action": "KPROBE_ACTION_POST"
  },
  "node_name": "rok-20-1",
  "time": "2025-08-21T10:24:17.261555091Z"
}

Similar issue was reported here https://github.com/cilium/tetragon/issues/2639. However, it was not tested on a plain Docker environment. I'm curious if I'm missing something.

Tetragon Version

v1.5.0

Kernel Version

uname -a

Linux rok-20-1 6.8.0-71-generic #71-Ubuntu SMP PREEMPT_DYNAMIC Tue Jul 22 16:52:38 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Kubernetes Version

not applicable

Bugtool

tetra bugtool

level=info msg="saving init info" level=info msg="retrieving lib directory" libDir=/usr/local/lib/tetragon/bpf level=warn msg="not an object file, ignoring" path=/usr/local/lib/tetragon/bpf level=warn msg="no btf filename in tetragon config, attempting to fall back to /sys/kernel/btf/vmlinux" level=info msg="btf file added" btfFname=/sys/kernel/btf/vmlinux level=info msg="tetragon log file added" exportFname=/var/log/tetragon/tetragon.log level=info msg="contacting metrics server" metricsAddr=http://localhost:2112/metrics level=info msg="executed command" cmd=/usr/bin/dmesg ret=0 dstFname=dmesg.out level=info msg="executed command" cmd="/usr/sbin/tc filter show dev lo ingress" ret=0 dstFname=tc-info.lo.ingress level=info msg="executed command" cmd="/usr/sbin/tc filter show dev lo egress" ret=0 dstFname=tc-info.lo.egress level=info msg="executed command" cmd="/usr/sbin/tc filter show dev enp5s0 ingress" ret=0 dstFname=tc-info.enp5s0.ingress level=info msg="executed command" cmd="/usr/sbin/tc filter show dev enp5s0 egress" ret=0 dstFname=tc-info.enp5s0.egress level=info msg="executed command" cmd="/usr/sbin/tc filter show dev docker0 ingress" ret=0 dstFname=tc-info.docker0.ingress level=info msg="executed command" cmd="/usr/sbin/tc filter show dev docker0 egress" ret=0 dstFname=tc-info.docker0.egress level=info msg="executed command" cmd="/usr/local/lib/tetragon/bpftool map show -j" ret=0 dstFname=bpftool-maps.json level=info msg="executed command" cmd="/usr/local/lib/tetragon/bpftool prog show -j" ret=0 dstFname=bpftool-progs.json level=info msg="executed command" cmd="/usr/local/lib/tetragon/bpftool cgroup tree -j" ret="exit status 255" dstFname=bpftool-cgroups.json level=info msg="Skipping gops dump info as daemon is running without gops, use --gops-address to enable gops" level=warn msg="failed to open policyfilter map" error="no such file or directory" level=info msg="dumped tracing policies in tracing-policies.json" level=info msg="executed command" cmd="/usr/bin/pmap -x 1276735" ret=0 dstFname=pmap.out level=info msg="cgroup file added" file=memory.current level=info msg="cgroup file added" file=memory.stat level=info msg="BPF maps checks added" file=debugmaps.json level=info msg="executed command" cmd="/usr/bin/cat /sys/kernel/tracing/trace" ret=0 dstFname=trace

Relevant log output

Anything else?

No response

[kkourt]

Hello!

The bugtool command should have created a tarball with some debugging information. In addition to the above, having the agent log would also be useful.

If this is a k8s cluster, the easiest way to gather this information is via a sysdump as described in https://tetragon.io/docs/troubleshooting/#automatic-log--state-collection.

[rnosal]

Hello,

Thank you for the quick answer.

This is not k8s cluster, this is my case: Systemd host installation.

Below are the logs after a Tetragon restart (debug mode): tetragon.log

Unfortunately, I can't upload a .tar.gz file. I received this message: "Failed to upload "tetragon-bugtool.tar.gz""

Maybe size it is too big?

[kkourt]

Process and its network connections are captured successfully, but they are not enriched with any container information.

This is not k8s cluster, this is my case: Systemd host installation.

Tetragon supports pod/container association only in k8s (at least currently), so what you observe is expected behavior.

[rnosal]

Thank you for the clarification.

Do you have any open ticket for it, so I can subscribe? I would love to see such a feature on bare metal hosts.

[kkourt]

Thank you for the clarification.

Do you have any open ticket for it, so I can subscribe? I would love to see such a feature on bare metal hosts.

I'm not aware of an existing issue for this. You are welcome to create one, if one does not exist already.