k8smeta: Document collectorHostname and nodeName configuration keys when running in Daemonset

[pentago]

What to document

Currently, docs state:

The plugin specifically acquires data for the node where the associated Falco instance is deployed, resulting in node-level granularity. In contrast, the collector runs at the cluster level. This implies that within a given cluster, there may be multiple k8smeta plugins (one per node), but there is only one collector.

Configuration example states:

      - name: k8smeta
        # path to the plugin .so file
        library_path: libk8smeta.so
        init_config:
          # port exposed by the k8s-metacollector (required)
          collectorPort: 45000
          # hostname exposed by the k8s-metacollector (required)
          collectorHostname: localhost
          # name of the node on which the Falco instance is running. (required)
          nodeName: kind-control-plane
          # verbosity level for the plugin logger (optional)
          verbosity: warn # (default: info)
      - name: json
        library_path: libjson.so
        init_config: ""

It would be great to document whether nodeName can be configured dynamically to pull data from node environment when plugin runs on Falco as a daemonset and by extension, on multiple nodes.

If hardcoded to a string, these would be named the same on all nodes which isn't optimal as docs already mention granularity:

The plugin specifically acquires data for the node where the associated Falco instance is deployed, resulting in node-level granularity.

I think it's unnecessary to hardcode this values to a string as it can likely be pulled in from an API server. In case such functionality doesn't exist yet, it would be great to have an issue for that too.

Thoughts?

[Andreagit97]

ei @pentago! yes, every variable in the plugin config (and more in general in all the falco.yaml config) can be configured dynamically through an environment variable, for example, you can write something like

collectorHostname: ${MY_COLLECTOR_NAME}
nodeName: ${MY_NODE_NAME}

In our official helm chart, we use the Kubernetes downward API (https://kubernetes.io/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) to do exactly what you mentioned, we collect the node name into an ENV_VAR and we pass it to the plugin config.

[Andreagit97]

BTW you raised a good point, we could highlight it in the documentation!

[Andreagit97]

/assign @Andreagit97