LFS260, k8s Security - LAB7.4 - required modification in tracee s configmap

luigicucciolillo

I installed Tracee 0.24.1 on a kubeadm Kubernetes cluster with two nodes (control plane + worker).

The Tracee DaemonSet pods were starting and generating events correctly, but both stayed in 0/1 Running because the readiness probe was failing.

The error was:

Readiness probe failed:
Get "http://<pod-ip>:3366/healthz":
dial tcp <pod-ip>:3366: connect: connection refused

The Tracee process itself was clearly working because logs contained normal eBPF events and detections.

The ConfigMap originally contained:

perf-buffer-size: 1024
healthz: true
metrics: true
pprof: false
pyroscope: false
listen-addr: :3366

The pod was correctly started with:

["/tracee/tracee"]
["--config","/tracee/config.yaml"]

and /tracee/config.yaml inside the container contained the expected configuration.

However, port 3366 was not listening.

Running:

/tracee/tracee --help

showed that this Tracee version exposes the HTTP server configuration through the --server option:

--server stringArray

Examples:
http-address=:3366
metrics
healthz
pprof
pyroscope

I therefore changed the ConfigMap from the old top-level server options to:

perf-buffer-size: 1024

server:
  - http-address=:3366
  - metrics
  - healthz

log:
  level: info

output:
  json:
    files:
      - stdout
    options:
      parse-arguments: true
      stack-addresses: false
      exec-env: false
      exec-hash: dev-inode
      sort-events: false

I applied the change with:

kubectl -n tracee patch configmap tracee-config \
  --type merge \
  --patch "$(cat <<'EOF'
data:
  config.yaml: |-
    perf-buffer-size: 1024
    server:
      - http-address=:3366
      - metrics
      - healthz
    log:
      level: info
    output:
      json:
        files:
          - stdout
      options:
        parse-arguments: true
        stack-addresses: false
        exec-env: false
        exec-hash: dev-inode
        sort-events: false
EOF
)"

Then restarted the DaemonSet:

kubectl -n tracee rollout restart daemonset tracee

After the restart, both Tracee pods became healthy:

tracee-hjcj9   1/1   Running
tracee-xdmz6   1/1   Running

So the issue was not Tracee itself, the CNI, or the readiness probe definition. The problem was that the old-style configuration did not start the HTTP health server on port 3366, while the newer server: configuration did.