Tracee not reflecting configuration changes from configmap in Kubernetes deployment

[takinaga-dev]

Description

Hello, I've followed the official guide for deploying Tracee on Kubernetes using Helm. I encountered an issue where the logs display outputs in table format, even though I've set the output to be in json format as recommended in the verification step. Even after updating the configuration in the configmap and restarting, the changes don't seem to be reflected.

Environment

OS: Ubuntu 20.04
Docker version: 24.0.5
Kind version: v0.20.0
Tracee version: 0.17

configuration file

Name: tracee-config
Namespace: tracee-system
Labels:
  app.kubernetes.io/instance: tracee
  app.kubernetes.io/managed-by: Helm
  app.kubernetes.io/name: tracee
  app.kubernetes.io/version: 0.17.0
  helm.sh/chart: tracee-0.17.0
Annotations:
  meta.helm.sh/release-name: tracee
  meta.helm.sh/release-namespace: tracee-system
Data:
  config.yaml:
    perf-buffer-size: 1024
    containers: true
    healthz: true
    metrics: true
    pprof: false
    pyroscope: false
    listen-addr: :3366
    cache:
      - cache-type=mem
      - mem-cache-size=512
    log:
      - info
    output:
      - json
      - option:parse-arguments

Step to reproduce

• Deploy Tracee using Helm as per the official guide.
• Check the logs and observe the output is in table format.
• Update the configmap to change output format. reference url
• Restart Tracee.
• Notice the changes are not reflected.

Expected Behavior

$  kubectl -n tracee-system logs -f ds/tracee

// show the json style output like document(https://aquasecurity.github.io/tracee/v0.17/getting-started/kubernetes-quickstart/#exercising-a-security-event)

Actual Behavior

$  kubectl -n tracee-system logs -f ds/tracee

02:53:18:894416  0      sudo             126364  126364  0                setuid                    uid: 0
02:53:18:894449  0      sudo             126364  126364  0                setgid                    gid: 0

Is there something I might be missing? Or is there any additional configuration or steps required to have the changes in the configmap reflected in the Tracee application? Any help or insights would be greatly appreciated.

[josedonizetti]

@takinaga-dev Thanks for reporting it, this is actually a bug we on the last release, I've raise an issue to fix it, and we will be soon releasing a bug fix version. #3369

[josedonizetti]

@takinaga-dev if you have the time, do you mind testing the latest release 0.17.1? This bug should have been addressed.

[takinaga-dev]

@josedonizetti
I checked latest release. see following logs by this tutorial

{"timestamp":1692260391188433336,"threadStartTime":1692260388928652912,"processorId":1,"processId":17,"cgroupId":2596,"threadId":17,"parentProcessId":16,"hostProcessId":42914,"hostThreadId":42914,"hostParentProcessId":42913,"userId":0,"mountNamespace":4026533580,"pidNamespace":4026533581,"processName":"3","hostName":"tracee-tester","containerId":"","container":{"id":"8f0f10f3e0e234536b8e99fdf1df50c1245decd18b881e9fe90c64106d2d6f77"},"kubernetes":{},"eventId":"6023","eventName":"fileless_execution","matchedPolicies":["signature-events"],"argsNum":0,"returnValue":0,"syscall":"","stackAddresses":null,"contextFlags":{"containerStarted":true,"isCompat":false},"args":[],"metadata":{"Version":"1","Description":"Fileless execution was detected. Executing a process from memory instead from a file in the filesystem may indicate that an adversary is trying to avoid execution detection.","Tags":null,"Properties":{"Category":"defense-evasion","Kubernetes_Technique":"","Severity":3,"Technique":"Reflective Code Loading","external_id":"T1620","id":"attack-pattern--4933e63b-9b77-476e-ab29-761bc5b7d15a","signatureID":"TRC-105","signatureName":"Fileless execution detected"}}}

it works fine.
thank you for quick response and release it.