# Default values for Falco.

###############################
# General deployment settings #
###############################

image:
  # -- The image pull policy.
  pullPolicy: IfNotPresent
  # -- The image registry to pull from.
  registry: docker.io
  # -- The image repository to pull from
  repository: falcosecurity/falco-no-driver
  # -- The image tag to pull. Overrides the image tag whose default is the chart appVersion.
  tag: ""

# -- Secrets containing credentials when pulling from private/secure registries.
imagePullSecrets: []
# -- Put here the new name if you want to override the release name used for Falco components.
nameOverride: ""
# -- Same as nameOverride but for the fullname.
fullnameOverride: ""
# -- Override the deployment namespace
namespaceOverride: ""

# -- Add additional pod annotations
podAnnotations: {}

serviceAccount:
  # -- Specifies whether a service account should be created.
  create: false
  # -- Annotations to add to the service account.
  annotations: {}
  # -- The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  name: ""

# -- Add additional pod labels
podLabels: {}

# -- Set pod priorityClassName
podPriorityClassName:

# -- Set securityContext for the pods
# These security settings are overriden by the ones specified for the specific
# containers when there is overlap.
podSecurityContext: {}

# Note that `containerSecurityContext`:
#  - will not apply to init containers, if any;
#  - takes precedence over other automatic configurations (see below).
#
# Based on the `driver` configuration the auto generated settings are:
# 1) driver.enabled = false:
#    securityContext: {}
#
# 2) driver.enabled = true and (driver.kind = module || driver.kind = modern-bpf):
#    securityContext:
#     privileged: true
#
# 3) driver.enabled = true and driver.kind = ebpf:
#    securityContext:
#     privileged: true
#
# 4) driver.enabled = true and driver.kind = ebpf and driver.ebpf.leastPrivileged = true
#    securityContext:
#     capabilities:
#      add:
#      - BPF
#      - SYS_RESOURCE
#      - PERFMON
#      - SYS_PTRACE
#
# -- Set securityContext for the Falco container.For more info see the "falco.securityContext" helper in "pod-template.tpl"
containerSecurityContext: {}

scc:
  # -- Create OpenShift's Security Context Constraint.
  create: true

resources:
  # -- Although resources needed are subjective on the actual workload we provide
  # a sane defaults ones. If you have more questions or concerns, please refer
  # to #falco slack channel for more info about it.
  requests:
    cpu: 100m
    memory: 512Mi
  # -- Maximum amount of resources that Falco container could get.
  # If you are enabling more than one source in falco, than consider to increase
  # the cpu limits.
  limits:
    cpu: 1000m
    memory: 1024Mi
# -- Selectors used to deploy Falco on a given node/nodes.
nodeSelector: {}

# -- Affinity constraint for pods' scheduling.
affinity: {}

# -- Tolerations to allow Falco to run on Kubernetes masters.
tolerations:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
  - effect: NoSchedule
    key: node-role.kubernetes.io/control-plane

# -- Parameters used
healthChecks:
  livenessProbe:
    # -- Tells the kubelet that it should wait X seconds before performing the first probe.
    initialDelaySeconds: 60
    # -- Number of seconds after which the probe times out.
    timeoutSeconds: 5
    # -- Specifies that the kubelet should perform the check every x seconds.
    periodSeconds: 15
  readinessProbe:
    # -- Tells the kubelet that it should wait X seconds before performing the first probe.
    initialDelaySeconds: 30
    # -- Number of seconds after which the probe times out.
    timeoutSeconds: 5
    # -- Specifies that the kubelet should perform the check every x seconds.
    periodSeconds: 15

# -- Attach the Falco process to a tty inside the container. Needed to flush Falco logs as soon as they are emitted.
# Set it to "true" when you need the Falco logs to be immediately displayed.
tty: false

#########################
# Scenario requirements #
#########################

# Sensors dislocation configuration (scenario requirement)
controller:
  # Available options: deployment, daemonset.
  kind: daemonset
  # Annotations to add to the daemonset or deployment
  annotations: {}
  daemonset:
    updateStrategy:
      # You can also customize maxUnavailable or minReadySeconds if you
      # need it
      # -- Perform rolling updates by default in the DaemonSet agent
      # ref: https://kubernetes.io/docs/tasks/manage-daemon/update-daemon-set/
      type: RollingUpdate
  deployment:
    # -- Number of replicas when installing Falco using a deployment. Change it if you really know what you are doing.
    # For more info check the section on Plugins in the README.md file.
    replicas: 1
    # -- Number of old history to retain to allow rollback (If not set, default Kubernetes value is set to 10)
    # revisionHistoryLimit: 1

# -- Network services configuration (scenario requirement)
# Add here your services to be deployed together with Falco.
services:
  # Example configuration for the "k8sauditlog" plugin
  # - name: k8saudit-webhook
  #   type: NodePort
  #   ports:
  #     - port: 9765 # See plugin open_params
  #       nodePort: 30007
  #       protocol: TCP

# File access configuration (scenario requirement)
mounts:
  # -- A list of volumes you want to add to the Falco pods.
  volumes: []
  # -- A list of volumes you want to add to the Falco pods.
  volumeMounts: []
  # -- By default, `/proc` from the host is only mounted into the Falco pod when `driver.enabled` is set to `true`. This flag allows it to override this behaviour for edge cases where `/proc` is needed but syscall data source is not enabled at the same time (e.g. for specific plugins).
  enforceProcMount: false

# Driver settings (scenario requirement)
driver:
  # -- Set it to false if you want to deploy Falco without the drivers.
  # Always set it to false when using Falco with plugins.
  enabled: true
  # -- kind tells Falco which driver to use. Available options: kmod (kernel driver), ebpf (eBPF probe), modern_ebpf (modern eBPF probe).
  kind: kmod
  # -- kmod holds the configuration for the kernel module.
  kmod:
    # -- bufSizePreset determines the size of the shared space between Falco and its drivers.
    # This shared space serves as a temporary storage for syscall events.
    bufSizePreset: 4
    # -- dropFailedExit if set true drops failed system call exit events before pushing them to userspace.
    dropFailedExit: false
  # -- Configuration section for ebpf driver.
  ebpf:
    # -- path where the eBPF probe is located. It comes handy when the probe have been installed in the nodes using tools other than the init
    # container deployed with the chart.
    path: "${HOME}/.falco/falco-bpf.o"
    # -- Needed to enable eBPF JIT at runtime for performance reasons.
    # Can be skipped if eBPF JIT is enabled from outside the container
    hostNetwork: false
    # -- Constrain Falco with capabilities instead of running a privileged container.
    # Ensure the eBPF driver is enabled (i.e., setting the `driver.kind` option to `ebpf`).
    # Capabilities used: {CAP_SYS_RESOURCE, CAP_SYS_ADMIN, CAP_SYS_PTRACE}.
    # On kernel versions >= 5.8 'CAP_PERFMON' and 'CAP_BPF' could replace 'CAP_SYS_ADMIN' but please pay attention to the 'kernel.perf_event_paranoid' value on your system.
    # Usually 'kernel.perf_event_paranoid>2' means that you cannot use 'CAP_PERFMON' and you should fallback to 'CAP_SYS_ADMIN', but the behavior changes across different distros.
    # Read more on that here: https://falco.org/docs/event-sources/kernel/#least-privileged-mode-1
    leastPrivileged: false
    # -- bufSizePreset determines the size of the shared space between Falco and its drivers.
    # This shared space serves as a temporary storage for syscall events.
    bufSizePreset: 4
    # -- dropFailedExit if set true drops failed system call exit events before pushing them to userspace.
    dropFailedExit: false
  modernEbpf:
    # -- Constrain Falco with capabilities instead of running a privileged container.
    # Ensure the modern bpf driver is enabled (i.e., setting the `driver.kind` option to `modern-bpf`).
    # Capabilities used: {CAP_SYS_RESOURCE, CAP_BPF, CAP_PERFMON, CAP_SYS_PTRACE}.
    # Read more on that here: https://falco.org/docs/event-sources/kernel/#least-privileged-mode-2
    leastPrivileged: false
    # -- bufSizePreset determines the size of the shared space between Falco and its drivers.
    # This shared space serves as a temporary storage for syscall events.
    bufSizePreset: 4
    # -- dropFailedExit if set true drops failed system call exit events before pushing them to userspace.
    dropFailedExit: false
    # -- cpusForEachBuffer is the index that controls how many CPUs to assign to a single syscall buffer.
    cpusForEachBuffer: 2

  # -- Gvisor configuration. Based on your system you need to set the appropriate values.
  # Please, remember to add pod tolerations and affinities in order to schedule the Falco pods in the gVisor enabled nodes.
  gvisor:
    # -- Runsc container runtime configuration. Falco needs to interact with it in order to intercept the activity of the sandboxed pods.
    runsc:
      # -- Absolute path of the `runsc` binary in the k8s nodes.
      path: /home/containerd/usr/local/sbin
      # -- Absolute path of the root directory of the `runsc` container runtime. It is of vital importance for Falco since `runsc` stores there the information of the workloads handled by it;
      root: /run/containerd/runsc
      # -- Absolute path of the `runsc` configuration file, used by Falco to set its configuration and make aware `gVisor` of its presence.
      config: /run/containerd/runsc/config.toml

  # -- Configuration for the Falco init container.
  loader:
    # -- Enable/disable the init container.
    enabled: true
    initContainer:
      image:
        # -- The image pull policy.
        pullPolicy: IfNotPresent
        # -- The image registry to pull from.
        registry: docker.io
        # -- The image repository to pull from.
        repository: falcosecurity/falco-driver-loader
        #  -- Overrides the image tag whose default is the chart appVersion.
        tag: ""
      # -- Extra environment variables that will be pass onto Falco driver loader init container.
      env: []
      # -- Arguments to pass to the Falco driver loader init container.
      args: []
      # -- Resources requests and limits for the Falco driver loader init container.
      resources: {}
      # -- Security context for the Falco driver loader init container. Overrides the default security context. If driver.kind == "module" you must at least set `privileged: true`.
      securityContext: {}

# Collectors for data enrichment (scenario requirement)
collectors:
  # -- Enable/disable all the metadata collectors.
  enabled: true

  docker:
    # -- Enable Docker support.
    enabled: true
    # -- The path of the Docker daemon socket.
    socket: /var/run/docker.sock

  containerd:
    # -- Enable ContainerD support.
    enabled: true
    # -- The path of the ContainerD socket.
    socket: /run/containerd/containerd.sock

  crio:
    # -- Enable CRI-O support.
    enabled: true
    # -- The path of the CRI-O socket.
    socket: /run/crio/crio.sock

  # -- kubernetes holds the configuration for the kubernetes collector. Starting from version 0.37.0 of Falco, the legacy
  # kubernetes client has been removed. A new standalone component named k8s-metacollector and a Falco plugin have been developed
  # to solve the issues that were present in the old implementation. More info here: https://github.com/falcosecurity/falco/issues/2973
  kubernetes:
    # -- enabled specifies whether the Kubernetes metadata should be collected using the k8smeta plugin and the k8s-metacollector component.
    # It will deploy the k8s-metacollector external component that fetches Kubernetes metadata and pushes them to Falco instances.
    # For more info see:
    # https://github.com/falcosecurity/k8s-metacollector
    # https://github.com/falcosecurity/charts/tree/master/charts/k8s-metacollector
    # When this option is disabled, Falco falls back to the container annotations to grab the metadata.
    # In such a case, only the ID, name, namespace, labels of the pod will be available.
    enabled: false
    # --pluginRef is the OCI reference for the k8smeta plugin. It could be a full reference such as:
    # "ghcr.io/falcosecurity/plugins/plugin/k8smeta:0.1.0". Or just name + tag: k8smeta:0.1.0.
    pluginRef: "ghcr.io/falcosecurity/plugins/plugin/k8smeta:0.1.0"
    # -- collectorHostname is the address of the k8s-metacollector. When not specified it will be set to match
    # k8s-metacollector service. e.x: falco-k8smetacollecto.falco.svc. If for any reason you need to override
    # it, make sure to set here the address of the k8s-metacollector.
    # It is used by the k8smeta plugin to connect to the k8s-metacollector.
    collectorHostname: ""
    # -- collectorPort designates the port on which the k8s-metacollector gRPC service listens. If not specified
    # the value of the port named `broker-grpc` in k8s-metacollector.service.ports is used. The default values is 45000.
    # It is used by the k8smeta plugin to connect to the k8s-metacollector.
    collectorPort: ""


###########################
# Extras and customization #
############################

extra:
  # -- Extra environment variables that will be pass onto Falco containers.
  env: []
  # -- Extra command-line arguments.
  args: []
  # -- Additional initContainers for Falco pods.
  initContainers: []

# -- certificates used by webserver and grpc server.
# paste certificate content or use helm with --set-file
# or use existing secret containing key, crt, ca as well as pem bundle
certs:
  # -- Existing secret containing the following key, crt and ca as well as the bundle pem.
  existingSecret: ""
  server:
    # -- Key used by gRPC and webserver.
    key: ""
    # -- Certificate used by gRPC and webserver.
    crt: ""
  ca:
    # -- CA certificate used by gRPC, webserver and AuditSink validation.
    crt: ""
  existingClientSecret: ""
  client:
    # -- Key used by http mTLS client.
    key: ""
    # -- Certificate used by http mTLS client.
    crt: ""

# -- Third party rules enabled for Falco. More info on the dedicated section in README.md file.
customRules:
  {}
  # Although Falco comes with a nice default rule set for detecting weird
  # behavior in containers, our users are going to customize the run-time
  # security rule sets or policies for the specific container images and
  # applications they run. This feature can be handled in this section.
  #
  # Example:
  #
  # rules-traefik.yaml: |-
  #   [ rule body ]

########################
# Falco integrations   #
########################

# -- For configuration values, see https://github.com/falcosecurity/charts/blob/master/charts/falcosidekick/values.yaml
falcosidekick:
  # -- Enable falcosidekick deployment.
  enabled: false
  # -- Enable usage of full FQDN of falcosidekick service (useful when a Proxy is used).
  fullfqdn: false
  # -- Listen port. Default value: 2801
  listenPort: ""

####################
# falcoctl config  #
####################
falcoctl:
  image:
    # -- The image pull policy.
    pullPolicy: IfNotPresent
    # -- The image registry to pull from.
    registry: docker.io
    # -- The image repository to pull from.
    repository: falcosecurity/falcoctl
    # -- The image tag to pull.
    tag: "0.7.2"
  artifact:
    # -- Runs "falcoctl artifact install" command as an init container. It is used to install artfacts before
    # Falco starts. It provides them to Falco by using an emptyDir volume.
    install:
      enabled: true
      # -- Extra environment variables that will be pass onto falcoctl-artifact-install init container.
      env: []
      # -- Arguments to pass to the falcoctl-artifact-install init container.
      args: ["--log-format=json"]
      # -- Resources requests and limits for the falcoctl-artifact-install init container.
      resources: {}
      # -- Security context for the falcoctl init container.
      securityContext: {}
      # -- A list of volume mounts you want to add to the falcoctl-artifact-install init container.
      mounts:
        volumeMounts: []
    # -- Runs "falcoctl artifact follow" command as a sidecar container. It is used to automatically check for
    # updates given a list of artifacts. If an update is found it downloads and installs it in a shared folder (emptyDir)
    # that is accessible by Falco. Rulesfiles are automatically detected and loaded by Falco once they are installed in the
    # correct folder by falcoctl. To prevent new versions of artifacts from breaking Falco, the tool checks if it is compatible
    # with the running version of Falco before installing it.
    follow:
      enabled: true
      # -- Extra environment variables that will be pass onto falcoctl-artifact-follow sidecar container.
      env: []
      # -- Arguments to pass to the falcoctl-artifact-follow sidecar container.
      args: ["--log-format=json"]
      # -- Resources requests and limits for the falcoctl-artifact-follow sidecar container.
      resources: {}
      # -- Security context for the falcoctl-artifact-follow sidecar container.
      securityContext: {}
      # -- A list of volume mounts you want to add to the falcoctl-artifact-follow sidecar container.
      mounts:
        volumeMounts: []
  # -- Configuration file of the falcoctl tool. It is saved in a configmap and mounted on the falcotl containers.
  config:
    # -- List of indexes that falcoctl downloads and uses to locate and download artiafcts. For more info see:
    # https://github.com/falcosecurity/falcoctl/blob/main/proposals/20220916-rules-and-plugin-distribution.md#index-file-overview
    indexes:
    - name: falcosecurity
      url: https://falcosecurity.github.io/falcoctl/index.yaml
    # -- Configuration used by the artifact commands.
    artifact:
      # -- List of artifact types that falcoctl will handle. If the configured refs resolves to an artifact whose type is not contained
      # in the list it will refuse to downloade and install that artifact.
      allowedTypes:
        - rulesfile
        - plugin
      install:
        # -- Resolve the dependencies for artifacts.
        resolveDeps: true
        # -- List of artifacts to be installed by the falcoctl init container.
        refs: [falco-rules:3]
        # -- Directory where the rulesfiles are saved. The path is relative to the container, which in this case is an emptyDir
        # mounted also by the Falco pod.
        rulesfilesDir: /rulesfiles
        # -- Same as the one above but for the artifacts.
        pluginsDir: /plugins
      follow:
        # -- List of artifacts to be followed by the falcoctl sidecar container.
        refs: [falco-rules:3]
        # -- How often the tool checks for new versions of the followed artifacts.
        every: 6h
        # -- HTTP endpoint that serves the api versions of the Falco instance. It is used to check if the new versions are compatible
        # with the running Falco instance.
        falcoversions: http://localhost:8765/versions
        # -- See the fields of the artifact.install section.
        rulesfilesDir: /rulesfiles
        # -- See the fields of the artifact.install section.
        pluginsDir: /plugins

######################
# falco.yaml config  #
######################
falco:
  #####################
  # Falco rules files #
  #####################

  # [Stable] `rules_file`
  #
  # Falco rules can be specified using files or directories, which are loaded at
  # startup. The name "rules_file" is maintained for backwards compatibility. If
  # the entry is a file, it will be read directly. If the entry is a directory,
  # all files within that directory will be read in alphabetical order.
  #
  # The falco_rules.yaml file ships with the Falco package and is overridden with
  # every new software version. falco_rules.local.yaml is only created if it
  # doesn't already exist.
  #
  # To customize the set of rules, you can add your modifications to any file.
  # It's important to note that the files or directories are read in the order
  # specified here. In addition, rules are loaded by Falco in the order they
  # appear within each rule file.
  #
  # If you have any customizations intended to override a previous configuration,
  # make sure they appear in later files to take precedence. On the other hand, if
  # the conditions of rules with the same event type(s) have the potential to
  # overshadow each other, ensure that the more important rule appears first. This
  # is because rules are evaluated on a "first match wins" basis, where the first
  # rule that matches the conditions will be applied, and subsequent rules will
  # not be evaluated for the same event type.
  #
  # By arranging the order of files and rules thoughtfully, you can ensure that
  # desired customizations and rule behaviors are prioritized and applied as
  # intended.
  # -- The location of the rules files that will be consumed by Falco.
  rules_file:
    - /etc/falco/falco_rules.yaml
    - /etc/falco/falco_rules.local.yaml
    - /etc/falco/rules.d

  # [Experimental] `rule_matching`
  #
  # - Falco has to be performant when evaluating rules against events. To quickly
  # understand which rules could trigger on a specific event, Falco maintains
  # buckets of rules sharing the same event type in a map. Then, the lookup
  # in each bucket is performed through linear search. The `rule_matching`
  # configuration key's values are:
  #  - "first": when evaluating conditions of rules in a bucket, Falco will stop
  #    to evaluate rules if it finds a matching rules. Since rules are stored
  #    in buckets in the order they are defined in the rules files, this option
  #    could prevent other rules to trigger even if their condition is met, causing
  #    a shadowing problem.
  #  - "all": with this value Falco will continue evaluating all the rules
  #    stored in the bucket, so that multiple rules could be triggered upon one
  #    event.

  rule_matching: first


  # [Experimental] `outputs_queue`
  #
  # -- Falco utilizes tbb::concurrent_bounded_queue for handling outputs, and this parameter
  # allows you to customize the queue capacity. Please refer to the official documentation:
  # https://oneapi-src.github.io/oneTBB/main/tbb_userguide/Concurrent_Queue_Classes.html.
  # On a healthy system with optimized Falco rules, the queue should not fill up.
  # If it does, it is most likely happening due to the entire event flow being too slow,
  # indicating that the server is under heavy load.
  #
  # `capacity`: the maximum number of items allowed in the queue is determined by this value.
  # Setting the value to 0 (which is the default) is equivalent to keeping the queue unbounded.
  # In other words, when this configuration is set to 0, the number of allowed items is
  # effectively set to the largest possible long value, disabling this setting.
  #
  # In the case of an unbounded queue, if the available memory on the system is consumed,
  # the Falco process would be OOM killed. When using this option and setting the capacity,
  # the current event would be dropped, and the event loop would continue. This behavior mirrors
  # kernel-side event drops when the buffer between kernel space and user space is full.
  outputs_queue:
    capacity: 0


  #################
  # Falco plugins #
  #################

  # [Stable] `load_plugins` and `plugins`
  #
  # --- [Description]
  #
  # Falco plugins enable integration with other services in the your ecosystem.
  # They allow Falco to extend its functionality and leverage data sources such as
  # Kubernetes audit logs or AWS CloudTrail logs. This enables Falco to perform
  # fast on-host detections beyond syscalls and container events. The plugin
  # system will continue to evolve with more specialized functionality in future
  # releases.
  #
  # Please refer to the plugins repo at
  # https://github.com/falcosecurity/plugins/blob/master/plugins/ for detailed
  # documentation on the available plugins. This repository provides comprehensive
  # information about each plugin and how to utilize them with Falco.
  #
  # Please note that if your intention is to enrich Falco syscall logs with fields
  # such as `k8s.ns.name`, `k8s.pod.name`, and `k8s.pod.*`, you do not need to use
  # the `k8saudit` plugin. This information is automatically extracted from the
  # container runtime socket. The `k8saudit` plugin is specifically designed to
  # integrate with Kubernetes audit logs and is not required for basic enrichment
  # of syscall logs with Kubernetes-related fields.
  #
  # --- [Usage]
  #
  # Disabled by default, indicated by an empty `load_plugins` list. Each plugin meant
  # to be enabled needs to be listed as explicit list item.
  #
  # For example, if you want to use the `k8saudit` plugin,
  # ensure it is configured appropriately and then change this to:
  # load_plugins: [k8saudit, json]
  # -- Add here all plugins and their configuration. Please
  # consult the plugins documentation for more info. Remember to add the plugins name in
  # "load_plugins: []" in order to load them in Falco.
  load_plugins: []

  # -- Customize subsettings for each enabled plugin. These settings will only be
  # applied when the corresponding plugin is enabled using the `load_plugins`
  # option.
  plugins:
    - name: k8saudit
      library_path: libk8saudit.so
      init_config:
      #   maxEventSize: 262144
      #   webhookMaxBatchSize: 12582912
      #   sslCertificate: /etc/falco/falco.pem
      open_params: "http://:9765/k8s-audit"
    - name: cloudtrail
      library_path: libcloudtrail.so
      # see docs for init_config and open_params:
      # https://github.com/falcosecurity/plugins/blob/master/plugins/cloudtrail/README.md
    - name: json
      library_path: libjson.so
      init_config: ""

  ######################
  # Falco config files #
  ######################

  # [Stable] `watch_config_files`
  #
  # Falco monitors configuration and rule files for changes and automatically
  # reloads itself to apply the updated configuration when any modifications are
  # detected. This feature is particularly useful when you want to make real-time
  # changes to the configuration or rules of Falco without interrupting its
  # operation or losing its state. For more information about Falco's state
  # engine, please refer to the `base_syscalls` section.
  # -- Watch config file and rules files for modification.
  # When a file is modified, Falco will propagate new config,
  # by reloading itself.
  watch_config_files: true

  ##########################
  # Falco outputs settings #
  ##########################

  # [Stable] `time_format_iso_8601`
  #
  # -- When enabled, Falco will display log and output messages with times in the ISO
  # 8601 format. By default, times are shown in the local time zone determined by
  # the /etc/localtime configuration.
  time_format_iso_8601: false

  # [Stable] `priority`
  #
  # -- Any rule with a priority level more severe than or equal to the specified
  # minimum level will be loaded and run by Falco. This allows you to filter and
  # control the rules based on their severity, ensuring that only rules of a
  # certain priority or higher are active and evaluated by Falco. Supported
  # levels: "emergency", "alert", "critical", "error", "warning", "notice",
  # "info", "debug"
  priority: debug

  # [Stable] `json_output`
  #
  # -- When enabled, Falco will output alert messages and rules file
  # loading/validation results in JSON format, making it easier for downstream
  # programs to process and consume the data. By default, this option is disabled.
  json_output: false

  # [Stable] `json_include_output_property`
  #
  # -- When using JSON output in Falco, you have the option to include the "output"
  # property itself in the generated JSON output. The "output" property provides
  # additional information about the purpose of the rule. To reduce the logging
  # volume, it is recommended to turn it off if it's not necessary for your use
  # case.
  json_include_output_property: true

  # [Stable] `json_include_tags_property`
  #
  # -- When using JSON output in Falco, you have the option to include the "tags"
  # field of the rules in the generated JSON output. The "tags" field provides
  # additional metadata associated with the rule. To reduce the logging volume,
  # if the tags associated with the rule are not needed for your use case or can
  # be added at a later stage, it is recommended to turn it off.
  json_include_tags_property: true

  # [Stable] `buffered_outputs`
  #
  # -- Enabling buffering for the output queue can offer performance optimization,
  # efficient resource usage, and smoother data flow, resulting in a more reliable
  # output mechanism. By default, buffering is disabled (false).
  buffered_outputs: false

  # [Stable] `outputs`
  #
  # -- A throttling mechanism, implemented as a token bucket, can be used to control
  # the rate of Falco outputs. Each event source has its own rate limiter,
  # ensuring that alerts from one source do not affect the throttling of others.
  # The following options control the mechanism:
  #  - rate: the number of tokens (i.e. right to send a notification) gained per
  #    second. When 0, the throttling mechanism is disabled. Defaults to 0.
  #  - max_burst: the maximum number of tokens outstanding. Defaults to 1000.
  #
  # For example, setting the rate to 1 allows Falco to send up to 1000
  # notifications initially, followed by 1 notification per second. The burst
  # capacity is fully restored after 1000 seconds of no activity.
  #
  # Throttling can be useful in various scenarios, such as preventing notification
  # floods, managing system load, controlling event processing, or complying with
  # rate limits imposed by external systems or APIs. It allows for better resource
  # utilization, avoids overwhelming downstream systems, and helps maintain a
  # balanced and controlled flow of notifications.
  #
  # With the default settings, the throttling mechanism is disabled.
  outputs:
    rate: 0
    max_burst: 1000

  ##########################
  # Falco outputs channels #
  ##########################

  # Falco supports various output channels, such as syslog, stdout, file, gRPC,
  # webhook, and more. You can enable or disable these channels as needed to
  # control where Falco alerts and log messages are directed. This flexibility
  # allows seamless integration with your preferred logging and alerting systems.
  # Multiple outputs can be enabled simultaneously.

  # [Stable] `stdout_output`
  #
  # -- Redirect logs to standard output.
  stdout_output:
    enabled: true

  # [Stable] `syslog_output`
  #
  # -- Send logs to syslog.
  syslog_output:
    enabled: true

  # [Stable] `file_output`
  #
  # -- When appending Falco alerts to a file, each new alert will be added to a new
  # line. It's important to note that Falco does not perform log rotation for this
  # file. If the `keep_alive` option is set to `true`, the file will be opened once
  # and continuously written to, else the file will be reopened for each output
  # message. Furthermore, the file will be closed and reopened if Falco receives
  # the SIGUSR1 signal.
  file_output:
    enabled: false
    keep_alive: false
    filename: ./events.txt

  # [Stable] `http_output`
  #
  # -- Send logs to an HTTP endpoint or webhook.
  http_output:
    enabled: false
    url: ""
    user_agent: "falcosecurity/falco"
    # -- Tell Falco to not verify the remote server.
    insecure: false
    # -- Path to the CA certificate that can verify the remote server.
    ca_cert: ""
    # -- Path to a specific file that will be used as the CA certificate store.
    ca_bundle: ""
    # -- Path to a folder that will be used as the CA certificate store. CA certificate need to be
    # stored as indivitual PEM files in this directory.
    ca_path: "/etc/falco/certs/"
    # -- Tell Falco to use mTLS
    mtls: false
    # -- Path to the client cert.
    client_cert: "/etc/falco/certs/client/client.crt"
    # -- Path to the client key.
    client_key: "/etc/falco/certs/client/client.key"
    # -- Whether to echo server answers to stdout
    echo: false
    # -- compress_uploads whether to compress data sent to http endpoint.
    compress_uploads: false
    # -- keep_alive whether to keep alive the connection.
    keep_alive: false

  # [Stable] `program_output`
  #
  # -- Redirect the output to another program or command.
  #
  # Possible additional things you might want to do with program output:
  #   - send to a slack webhook:
  #         program: "jq '{text: .output}' | curl -d @- -X POST https://hooks.slack.com/services/XXX"
  #   - logging (alternate method than syslog):
  #         program: logger -t falco-test
  #   - send over a network connection:
  #         program: nc host.example.com 80
  # If `keep_alive` is set to `true`, the program will be started once and
  # continuously written to, with each output message on its own line. If
  # `keep_alive` is set to `false`, the program will be re-spawned for each output
  # message. Furthermore, the program will be re-spawned if Falco receives
  # the SIGUSR1 signal.
  program_output:
    enabled: false
    keep_alive: false
    program: "jq '{text: .output}' | curl -d @- -X POST https://hooks.slack.com/services/XXX"

  # [Stable] `grpc_output`
  #
  # -- Use gRPC as an output service.
  #
  # gRPC is a modern and high-performance framework for remote procedure calls
  # (RPC). It utilizes protocol buffers for efficient data serialization. The gRPC
  # output in Falco provides a modern and efficient way to integrate with other
  # systems. By default the setting is turned off. Enabling this option stores
  # output events in memory until they are consumed by a gRPC client. Ensure that
  # you have a consumer for the output events or leave it disabled.
  grpc_output:
    enabled: false

  ##########################
  # Falco exposed services #
  ##########################

  # [Stable] `grpc`
  #
  # Falco provides support for running a gRPC server using two main binding types:
  # 1. Over the network with mandatory mutual TLS authentication (mTLS), which
  #    ensures secure communication
  # 2. Local Unix socket binding with no authentication. By default, the
  #    gRPCserver in Falco is turned off with no enabled services (see
  #    `grpc_output`setting).
  #
  # To configure the gRPC server in Falco, you can make the following changes to
  # the options:
  #
  # - Uncomment the relevant configuration options related to the gRPC server.
  # - Update the paths of the generated certificates for mutual TLS authentication
  #   if you choose to use mTLS.
  # - Specify the address to bind and expose the gRPC server.
  # - Adjust the threadiness configuration to control the number of threads and
  #   contexts used by the server.
  #
  # Keep in mind that if any issues arise while creating the gRPC server, the
  # information will be logged, but it will not stop the main Falco daemon.

  # gRPC server using mTLS
  # grpc:
  #   enabled: true
  #   bind_address: "0.0.0.0:5060"
  #   # When the `threadiness` value is set to 0, Falco will automatically determine
  #   # the appropriate number of threads based on the number of online cores in the system.
  #   threadiness: 0
  #   private_key: "/etc/falco/certs/server.key"
  #   cert_chain: "/etc/falco/certs/server.crt"
  #   root_certs: "/etc/falco/certs/ca.crt"

  # -- gRPC server using a local unix socket
  grpc:
    enabled: false
    bind_address: "unix:///run/falco/falco.sock"
    # -- When the `threadiness` value is set to 0, Falco will automatically determine
    # the appropriate number of threads based on the number of online cores in the system.
    threadiness: 0

  # [Stable] `webserver`
  #
  # -- Falco supports an embedded webserver that runs within the Falco process,
  # providing a lightweight and efficient way to expose web-based functionalities
  # without the need for an external web server. The following endpoints are
  # exposed:
  # - /healthz: designed to be used for checking the health and availability of
  #   the Falco application (the name of the endpoint is configurable).
  # - /versions: responds with a JSON object containing the version numbers of the
  #   internal Falco components (similar output as `falco --version -o
  #   json_output=true`).
  #
  # Please note that the /versions endpoint is particularly useful for other Falco
  # services, such as `falcoctl`, to retrieve information about a running Falco
  # instance. If you plan to use `falcoctl` locally or with Kubernetes, make sure
  # the Falco webserver is enabled.
  #
  # The behavior of the webserver can be controlled with the following options,
  # which are enabled by default:
  #
  # The `ssl_certificate` option specifies a combined SSL certificate and
  # corresponding key that are contained in a single file. You can generate a
  # key/cert as follows:
  #
  # $ openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out
  # certificate.pem $ cat certificate.pem key.pem > falco.pem $ sudo cp falco.pem
  # /etc/falco/falco.pem
  webserver:
    enabled: true
    # When the `threadiness` value is set to 0, Falco will automatically determine
    # the appropriate number of threads based on the number of online cores in the system.
    threadiness: 0
    listen_port: 8765
    k8s_healthz_endpoint: /healthz
    ssl_enabled: false
    ssl_certificate: /etc/falco/falco.pem

  ##############################################################################
  # Falco logging / alerting / metrics related to software functioning (basic) #
  ##############################################################################

  # [Stable] `log_stderr` and `log_syslog`
  #
  # Falco's logs related to the functioning of the software, which are not related
  # to Falco alert outputs but rather its lifecycle, settings and potential
  # errors, can be directed to stderr and/or syslog.
  # -- Send information logs to stderr. Note these are *not* security
  # notification logs! These are just Falco lifecycle (and possibly error) logs.
  log_stderr: true
  # -- Send information logs to syslog. Note these are *not* security
  # notification logs! These are just Falco lifecycle (and possibly error) logs.
  log_syslog: true

  # [Stable] `log_level`
  #
  # -- The `log_level` setting determines the minimum log level to include in Falco's
  # logs related to the functioning of the software. This setting is separate from
  # the `priority` field of rules and specifically controls the log level of
  # Falco's operational logging. By specifying a log level, you can control the
  # verbosity of Falco's operational logs. Only logs of a certain severity level
  # or higher will be emitted. Supported levels: "emergency", "alert", "critical",
  # "error", "warning", "notice", "info", "debug".
  log_level: info

  # [Stable] `libs_logger`
  #
  # -- The `libs_logger` setting in Falco determines the minimum log level to include
  # in the logs related to the functioning of the software of the underlying
  # `libs` library, which Falco utilizes. This setting is independent of the
  # `priority` field of rules and the `log_level` setting that controls Falco's
  # operational logs. It allows you to specify the desired log level for the `libs`
  # library specifically, providing more granular control over the logging
  # behavior of the underlying components used by Falco. Only logs of a certain
  # severity level or higher will be emitted. Supported levels: "emergency",
  # "alert", "critical", "error", "warning", "notice", "info", "debug". It is not
  # recommended for production use.
  libs_logger:
    enabled: false
    severity: debug

  #################################################################################
  # Falco logging / alerting / metrics related to software functioning (advanced) #
  #################################################################################

  # [Stable] `output_timeout`
  #
  # Generates Falco operational logs when `log_level=notice` at minimum
  #
  # A timeout error occurs when a process or operation takes longer to complete
  # than the allowed or expected time limit. In the context of Falco, an output
  # timeout error refers to the situation where an output channel fails to deliver
  # an alert within a specified deadline. Various reasons, such as network issues,
  # resource constraints, or performance bottlenecks can cause timeouts.
  #
  # -- The `output_timeout` parameter specifies the duration, in milliseconds, to
  # wait before considering the deadline exceeded. By default, the timeout is set
  # to 2000ms (2 seconds), meaning that the consumer of Falco outputs can block
  # the Falco output channel for up to 2 seconds without triggering a timeout
  # error.
  #
  # Falco actively monitors the performance of output channels. With this setting
  # the timeout error can be logged, but please note that this requires setting
  # Falco's operational logs `log_level` to a minimum of `notice`.
  #
  # It's important to note that Falco outputs will not be discarded from the
  # output queue. This means that if an output channel becomes blocked
  # indefinitely, it indicates a potential issue that needs to be addressed by the
  # user.
  output_timeout: 2000

  # [Stable] `syscall_event_timeouts`
  #
  # -- Generates Falco operational logs when `log_level=notice` at minimum
  #
  # Falco utilizes a shared buffer between the kernel and userspace to receive
  # events, such as system call information, in userspace. However, there may be
  # cases where timeouts occur in the underlying libraries due to issues in
  # reading events or the need to skip a particular event. While it is uncommon
  # for Falco to experience consecutive event timeouts, it has the capability to
  # detect such situations. You can configure the maximum number of consecutive
  # timeouts without an event after which Falco will generate an alert, but please
  # note that this requires setting Falco's operational logs `log_level` to a
  # minimum of `notice`. The default value is set to 1000 consecutive timeouts
  # without receiving any events. The mapping of this value to a time interval
  # depends on the CPU frequency.
  syscall_event_timeouts:
    max_consecutives: 1000

  # [Stable] `syscall_event_drops`
  #
  # Generates "Falco internal: syscall event drop" rule output when `priority=debug` at minimum
  #
  # --- [Description]
  #
  # Falco uses a shared buffer between the kernel and userspace to pass system
  # call information. When Falco detects that this buffer is full and system calls
  # have been dropped, it can take one or more of the following actions:
  #   - ignore: do nothing (default when list of actions is empty)
  #   - log: log a DEBUG message noting that the buffer was full
  #   - alert: emit a Falco alert noting that the buffer was full
  #   - exit: exit Falco with a non-zero rc
  #
  # Notice it is not possible to ignore and log/alert messages at the same time.
  #
  # The rate at which log/alert messages are emitted is governed by a token
  # bucket. The rate corresponds to one message every 30 seconds with a burst of
  # one message (by default).
  #
  # The messages are emitted when the percentage of dropped system calls with
  # respect the number of events in the last second is greater than the given
  # threshold (a double in the range [0, 1]). If you want to be alerted on any
  # drops, set the threshold to 0.
  #
  # For debugging/testing it is possible to simulate the drops using the
  # `simulate_drops: true`. In this case the threshold does not apply.
  #
  # --- [Usage]
  #
  # Enabled by default, but requires Falco rules config `priority` set to `debug`.
  # Emits a Falco rule named "Falco internal: syscall event drop" as many times in
  # a given time period as dictated by the settings. Statistics here reflect the
  # delta in a 1s time period.
  #
  # If instead you prefer periodic metrics of monotonic counters at a regular
  # interval, which include syscall drop statistics and additional metrics,
  # explore the `metrics` configuration option.
  # -- For debugging/testing it is possible to simulate the drops using
  # the `simulate_drops: true`. In this case the threshold does not apply.
  syscall_event_drops:
    # -- The messages are emitted when the percentage of dropped system calls
    # with respect the number of events in the last second
    # is greater than the given threshold (a double in the range [0, 1]).
    threshold: .1
    # -- Actions to be taken when system calls were dropped from the circular buffer.
    actions:
      - log
      - alert
    # -- Rate at which log/alert messages are emitted.
    rate: .03333
    # -- Max burst of messages emitted.
    max_burst: 1
    # -- Flag to enable drops for debug purposes.
    simulate_drops: false

  # [Experimental] `metrics`
  #
  # -- Generates "Falco internal: metrics snapshot" rule output when `priority=info` at minimum
  #
  # periodic metric snapshots (including stats and resource utilization) captured
  # at regular intervals
  #
  # --- [Description]
  #
  # Consider these key points about the `metrics` feature in Falco:
  #
  # - It introduces a redesigned stats/metrics system.
  # - Native support for resource utilization metrics and specialized performance
  #   metrics.
  # - Metrics are emitted as monotonic counters at predefined intervals
  #   (snapshots).
  # - All metrics are consolidated into a single log message, adhering to the
  #   established rules schema and naming conventions.
  # - Additional info fields complement the metrics and facilitate customized
  #   statistical analyses and correlations.
  # - The metrics framework is designed for easy future extension.
  #
  # The `metrics` feature follows a specific schema and field naming convention.
  # All metrics are collected as subfields under the `output_fields` key, similar
  # to regular Falco rules. Each metric field name adheres to the grammar used in
  # Falco rules. There are two new field classes introduced: `falco.` and `scap.`.
  # The `falco.` class represents userspace counters, statistics, resource
  # utilization, or useful information fields. The `scap.` class represents
  # counters and statistics mostly obtained from Falco's kernel instrumentation
  # before events are sent to userspace, but can include scap userspace stats as
  # well.
  #
  # It's important to note that the output fields and their names can be subject
  # to change until the metrics feature reaches a stable release.
  #
  # To customize the hostname in Falco, you can set the environment variable
  # `FALCO_HOSTNAME` to your desired hostname. This is particularly useful in
  # Kubernetes deployments where the hostname can be set to the pod name.
  #
  # --- [Usage]
  #
  # `enabled`: Disabled by default.
  #
  # `interval`: The stats interval in Falco follows the time duration definitions
  # used by Prometheus.
  # https://prometheus.io/docs/prometheus/latest/querying/basics/#time-durations
  #
  # Time durations are specified as a number, followed immediately by one of the
  # following units:
  #
  # ms - millisecond
  # s - second
  # m - minute
  # h - hour
  # d - day - assuming a day has always 24h
  # w - week - assuming a week has always 7d
  # y - year - assuming a year has always 365d
  #
  # Example of a valid time duration: 1h30m20s10ms
  #
  # A minimum interval of 100ms is enforced for metric collection. However, for
  # production environments, we recommend selecting one of the following intervals
  # for optimal monitoring:
  #
  # 15m
  # 30m
  # 1h
  # 4h
  # 6h
  #
  # `output_rule`: To enable seamless metrics and performance monitoring, we
  # recommend emitting metrics as the rule "Falco internal: metrics snapshot".
  # This option is particularly useful when Falco logs are preserved in a data
  # lake. Please note that to use this option, the Falco rules config `priority`
  # must be set to `info` at a minimum.
  #
  # `output_file`: Append stats to a `jsonl` file. Use with caution in production
  # as Falco does not automatically rotate the file.
  #
  # `resource_utilization_enabled`: Emit CPU and memory usage metrics. CPU usage
  # is reported as a percentage of one CPU and can be normalized to the total
  # number of CPUs to determine overall usage. Memory metrics are provided in raw
  # units (`kb` for `RSS`, `PSS` and `VSZ` or `bytes` for `container_memory_used`)
  # and can be uniformly converted to megabytes (MB) using the
  # `convert_memory_to_mb` functionality. In environments such as Kubernetes when
  # deployed as daemonset, it is crucial to track Falco's container memory usage.
  # To customize the path of the memory metric file, you can create an environment
  # variable named `FALCO_CGROUP_MEM_PATH` and set it to the desired file path. By
  # default, Falco uses the file `/sys/fs/cgroup/memory/memory.usage_in_bytes` to
  # monitor container memory usage, which aligns with Kubernetes'
  # `container_memory_working_set_bytes` metric. Finally, we emit the overall host
  # CPU and memory usages, along with the total number of processes and open file
  # descriptors (fds) on the host, obtained from the proc file system unrelated to
  # Falco's monitoring. These metrics help assess Falco's usage in relation to the
  # server's workload intensity.
  #
  # `state_counters_enabled`: Emit counters related to Falco's state engine, including
  # added, removed threads or file descriptors (fds), and failed lookup, store, or
  # retrieve actions in relation to Falco's underlying process cache table (threadtable).
  # We also log the number of currently cached containers if applicable.
  #
  # `kernel_event_counters_enabled`: Emit kernel side event and drop counters, as
  # an alternative to `syscall_event_drops`, but with some differences. These
  # counters reflect monotonic values since Falco's start and are exported at a
  # constant stats interval.
  #
  # `libbpf_stats_enabled`: Exposes statistics similar to `bpftool prog show`,
  # providing information such as the number of invocations of each BPF program
  # attached by Falco and the time spent in each program measured in nanoseconds.
  # To enable this feature, the kernel must be >= 5.1, and the kernel
  # configuration `/proc/sys/kernel/bpf_stats_enabled` must be set. This option,
  # or an equivalent statistics feature, is not available for non `*bpf*` drivers.
  # Additionally, please be aware that the current implementation of `libbpf` does
  # not support granularity of statistics at the bpf tail call level.
  #
  # `include_empty_values`: When the option is set to true, fields with an empty
  # numeric value will be included in the output. However, this rule does not
  # apply to high-level fields such as `n_evts` or `n_drops`; they will always be
  # included in the output even if their value is empty. This option can be
  # beneficial for exploring the data schema and ensuring that fields with empty
  # values are included in the output.
  # todo: prometheus export option
  # todo: syscall_counters_enabled option
  metrics:
    enabled: false
    interval: 1h
    output_rule: true
    # output_file: /tmp/falco_stats.jsonl
    resource_utilization_enabled: true
    state_counters_enabled: true
    kernel_event_counters_enabled: true
    libbpf_stats_enabled: true
    convert_memory_to_mb: true
    include_empty_values: false


  #######################################
  # Falco performance tuning (advanced) #
  #######################################

  # [Experimental] `base_syscalls`, use with caution, read carefully
  #
  # --- [Description]
  #
  # -- This option configures the set of syscalls that Falco traces.
  #
  # --- [Falco's State Engine]
  #
  # Falco requires a set of syscalls to build up state in userspace. For example,
  # when spawning a new process or network connection, multiple syscalls are
  # involved. Furthermore, properties of a process during its lifetime can be
  # modified by syscalls. Falco accounts for this by enabling the collection of
  # additional syscalls than the ones defined in the rules and by managing a smart
  # process cache table in userspace. Processes are purged from this table when a
  # process exits.
  #
  # By default, with
  #   ```
  #   base_syscalls.custom_set = []
  #   base_syscalls.repair = false
  #   ```
  # Falco enables tracing for a syscall set gathered: (1) from (enabled) Falco
  #   rules (2) from a static, more verbose set defined in
  #   `libsinsp::events::sinsp_state_sc_set` in
  #   libs/userspace/libsinsp/events/sinsp_events_ppm_sc.cpp This allows Falco to
  #   successfully build up it's state engine and life-cycle management.
  #
  # If the default behavior described above does not fit the user's use case for
  # Falco, the `base_syscalls` option allows for finer end-user control of
  # syscalls traced by Falco.
  #
  # --- [base_syscalls.custom_set]
  #
  # CAUTION: Misconfiguration of this setting may result in incomplete Falco event
  # logs or Falco being unable to trace events entirely.
  #
  # `base_syscalls.custom_set` allows the user to explicitly define an additional
  # set of syscalls to be traced in addition to the syscalls from each enabled
  # Falco rule.
  #
  # This is useful in lowering CPU utilization and further tailoring Falco to
  # specific environments according to your threat model and budget constraints.
  #
  # --- [base_syscalls.repair]
  #
  # `base_syscalls.repair` is an alternative to Falco's default state engine
  # enforcement. When enabled, this option is designed to (1) ensure that Falco's
  # state engine is correctly and successfully built-up (2) be the most system
  # resource-friendly by activating the least number of additional syscalls
  # (outside of those enabled for enabled rules)
  #
  # Setting `base_syscalls.repair` to `true` allows Falco to automatically
  # configure what is described in the [Suggestions] section below.
  #
  # `base_syscalls.repair` can be enabled with an empty custom set, meaning with
  # the following,
  #   ```
  #   base_syscalls.custom_set = []
  #   base_syscalls.repair = true
  #   ```
  # Falco enables tracing for a syscall set gathered: (1) from (enabled) Falco
  #   rules (2) from minimal set of additional syscalls needed to "repair" the
  #   state engine and properly log event conditions specified in enabled Falco
  #   rules
  #
  # --- [Usage]
  #
  # List of system calls names (<syscall-name>), negative ("!<syscall-name>")
  # notation supported.
  #
  # Example: base_syscalls.custom_set: [<syscall-name>, <syscall-name>,
  # "!<syscall-name>"] base_syscalls.repair: <bool>
  #
  # We recommend to only exclude syscalls, e.g. "!mprotect" if you need a fast
  # deployment update (overriding rules), else remove unwanted syscalls from the
  # Falco rules.
  #
  # Passing `-o "log_level=debug" -o "log_stderr=true" --dry-run` to Falco's cmd
  # args will print the final set of syscalls to STDOUT.
  #
  # --- [Suggestions]
  #
  # NOTE: setting `base_syscalls.repair: true` automates the following suggestions
  # for you.
  #
  # These suggestions are subject to change as Falco and its state engine evolve.
  #
  # For execve* events: Some Falco fields for an execve* syscall are retrieved
  # from the associated `clone`, `clone3`, `fork`, `vfork` syscalls when spawning
  # a new process. The `close` syscall is used to purge file descriptors from
  # Falco's internal thread / process cache table and is necessary for rules
  # relating to file descriptors (e.g. open, openat, openat2, socket, connect,
  # accept, accept4 ... and many more)
  #
  # Consider enabling the following syscalls in `base_syscalls.custom_set` for
  # process rules: [clone, clone3, fork, vfork, execve, execveat, close]
  #
  # For networking related events: While you can log `connect` or `accept*`
  # syscalls without the socket syscall, the log will not contain the ip tuples.
  # Additionally, for `listen` and `accept*` syscalls, the `bind` syscall is also
  # necessary.
  #
  # We recommend the following as the minimum set for networking-related rules:
  # [clone, clone3, fork, vfork, execve, execveat, close, socket, bind,
  # getsockopt]
  #
  # Lastly, for tracking the correct `uid`, `gid` or `sid`, `pgid` of a process
  # when the running process opens a file or makes a network connection, consider
  # adding the following to the above recommended syscall sets: ... setresuid,
  # setsid, setuid, setgid, setpgid, setresgid, setsid, capset, chdir, chroot,
  # fchdir ...
  base_syscalls:
    custom_set: []
    repair: false

  #################################################
  # Falco cloud orchestration systems integration #
  #################################################

  # [Stable] Guidance for Kubernetes container engine command-line args settings
  #
  # Modern cloud environments, particularly Kubernetes, heavily rely on
  # containerized workload deployments. When capturing events with Falco, it
  # becomes essential to identify the owner of the workload for which events are
  # being captured, such as syscall events. Falco integrates with the container
  # runtime to enrich its events with container information, including fields like
  # `container.image.repository`, `container.image.tag`, ... , `k8s.ns.name`,
  # `k8s.pod.name`, `k8s.pod.*` in the Falco output (Falco retrieves Kubernetes
  # namespace and pod name directly from the container runtime, see
  # https://falco.org/docs/reference/rules/supported-fields/#field-class-container).
  #
  # Furthermore, Falco exposes container events themselves as a data source for
  # alerting. To achieve this integration with the container runtime, Falco
  # requires access to the runtime socket. By default, for Kubernetes, Falco
  # attempts to connect to the following sockets:
  # "/run/containerd/containerd.sock", "/run/crio/crio.sock",
  # "/run/k3s/containerd/containerd.sock". If you have a custom path, you can use
  # the `--cri` option to specify the correct location.
  #
  # In some cases, you may encounter empty fields for container metadata. To
  # address this, you can explore the `--disable-cri-async` option, which disables
  # asynchronous fetching if the fetch operation is not completing quickly enough.
  #
  # To get more information on these command-line arguments, you can run `falco
  # --help` in your terminal to view their current descriptions.
  #
  # !!! The options mentioned here are not available in the falco.yaml
  # configuration file. Instead, they can can be used as a command-line argument
  # when running the Falco command.