[k8smeta] Plugin fails to initialize on numeric Kubernetes nodes due to strict String constraint vs Core Type Inference

[kmp142]

Describe the bug
When deploying Falco via the official Helm chart on a Kubernetes node that has a purely numeric hostname (e.g. 123456), the k8smeta plugin crashes during initialization.

The issue stems from a type mismatch between how the Falco C++ core parses downward API substitutions and how the k8smeta plugin validates its configuration schema:

1. The Falco C++ engine evaluates the environment variable substitution. Seeing a purely numeric value, its internal YAML/JSON parser infers the type as an Integer.
2. The k8smeta plugin's JSON schema strictly enforces type=string for the nodeName field.
3. The plugin initialization fails because it receives an Integer instead of a String.

How to reproduce it

1. Provision a Kubernetes node with a purely numeric name (e.g., 123456).
2. Deploy Falco using the official Helm chart with k8s-metacollector and the k8smeta plugin enabled.
3. The Helm chart correctly generates the ConfigMap with downward API substitution:

plugins:
  - init_config:
      nodeName: "${FALCO_K8S_NODE_NAME}"

4. But DaemonSet pods located on purely numeric named nodes fall into a CrashLoopBackOff state with the following error in the logs:

falco: Runtime error: error in plugin k8smeta init config: In <root>[nodeName], Value type not permitted by 'type' constraint.. Exiting.

Expected behaviour
The Falco core should preserve the String type context when substituting environment variables, or the plugin should accept numeric node names, allowing the DaemonSet pods to run on purely numeric named nodes without any schema validation errors.

Proposed Solutions

• Plugin-side (Easier): Relax the JSON schema in the k8smeta plugin to accept ["string", "integer"] for nodeName and cast it to a string internally in Go.
• Core-side: Fix the Falco core configuration parser so it does not lose the original String type context when substituting environment variables that happen to resolve to digits.

Environment

Falco and System Info (Click to expand)

• Falco version:

Sat May 23 19:02:18 2026: Falco version: 0.43.0 (x86_64)
Sat May 23 19:02:18 2026: Falco initialized with configuration files:
Sat May 23 19:02:18 2026:    /etc/falco/falco.yaml | schema validation: ok
Sat May 23 19:02:18 2026: System info: Linux version 5.15.0-177-generic (buildd@lcy02-amd64-099) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04.3) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #187-Ubuntu SMP Sat Apr 11 22:54:33 UTC 2026
{"default_driver_version":"9.1.0+driver","driver_api_version":"8.0.0","driver_schema_version":"4.1.0","engine_version":"58","engine_version_semver":"0.58.0","falco_version":"0.43.0","libs_version":"0.23.1","plugin_api_version":"3.12.0"}

• OS: Ubuntu 22.04.3
• Kernel: Linux 118 5.15.0-177-generic #187-Ubuntu SMP Sat Apr 11 22:54:33 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
• Installation method: Kubernetes Helm chart (falco-8.0.1)

Additional context

Note on Node Naming
I am well aware that using purely numeric hostnames for Kubernetes nodes is generally considered an edge case or a bad practice. However, since it is technically permitted by Kubernetes, this type mismatch issue still occurs in the wild and likely requires a robust fix to prevent unexpected DaemonSet crashes.

Workaround
To bypass this issue temporarily, we had to patch the Helm chart templates/configmap.yaml using a replace pipeline to inject the explicit YAML tag !!str along with escaped quotes before the downward API variable. This forces the parser to treat the substitution as a string:

  falco.yaml: |-
    {{- include "falco.falcosidekickConfig" . }}
    {{- include "k8smeta.configuration" . -}}
    {{- include "falco.engineConfiguration" . -}}
    {{- include "falco.metricsConfiguration" . -}}
    {{- include "falco.containerPlugin" . -}}
    {{- toYaml .Values.falco | replace "nodeName: ${FALCO_K8S_NODE_NAME}" "nodeName: \"!!str ${FALCO_K8S_NODE_NAME}\"" | nindent 4 }}