dnsPolicy should be set to ClusterFirstWithHostNet in pod template with gVisor driver

[NoOverflow]

Hi,

Describe the bug

The dnsPolicy attribute is currently only set to ClusterFirstWithHostNet when the driver kind is ebpf and hostNetwork is enabled.

charts/charts/falco/templates/pod-template.tpl

Lines 36 to 38 in 15f97d5

	{{- if and (eq .Values.driver.kind "ebpf") .Values.driver.ebpf.hostNetwork }}
	hostNetwork: true
	dnsPolicy: ClusterFirstWithHostNet

This is due to how dnsPolicy behaves when hostNetwork is true (https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy)

"ClusterFirstWithHostNet": For Pods running with hostNetwork, you should explicitly set its DNS policy to "ClusterFirstWithHostNet". Otherwise, Pods running with hostNetwork and "ClusterFirst" will fallback to the behavior of the "Default" policy."

The "Default" policy uses the DNS resolve configuration from the node, this effectively isolate the pod from resolving the IP of other pods/services on the cluster.

Since the dnsPolicy attribute is not set when the driver is gVisor, but the hostNetwork attribute is. This causes dnsPolicy to fallback to this Default mode.

charts/charts/falco/templates/pod-template.tpl

Lines 60 to 63 in 15f97d5

	{{- if eq .Values.driver.kind "gvisor" }}
	hostNetwork: true
	hostPID: true
	{{- end }}

This is an issue especially when you enable the http output to falcosidekick, because the URL is automatically set to falco-falcosidekick:2801 and fails to lookup, causing an issue similar to falcosecurity/falco#3142.

How to reproduce it

Deploy falco with the gVisor driver, and the falcosidekick pod enabled.

Example values file:

falcosidekick:
  enabled: true
driver:
  enabled: true
  kind: gvisor
  gvisor:
    enabled: true

Expected behaviour

dnsPolicy should be set to ClusterFirstWithHostNet when driver.kind: gvisor

[NoOverflow]

Fix commit on my fork, NoOverflow@c35f235. Let me know if you want me to open a PR :)

[Issif]

The setting

charts/charts/falco/values.yaml

Line 469 in 15f97d5

fullfqdn: false

set to true allows to use the fqdn and avoid the issue, right?

[NoOverflow]

The setting

charts/charts/falco/values.yaml

Line 469 in 15f97d5

fullfqdn: false

set to true allows to use the fqdn and avoid the issue, right?

This flag seems to only set the sidekick url in the configuration to the full URL, but it would still need to be able to resolve it using the Kubernetes internal DNS, so no I'm pretty sure it wouldn't avoid it

charts/charts/falco/templates/_helpers.tpl

Lines 140 to 144 in 15f97d5

	{{- if .Values.falcosidekick.fullfqdn -}}
	{{- printf "http://%s-falcosidekick.%s.svc.cluster.local:%s" $falcoName .Release.Namespace $listenPort -}}
	{{- else -}}
	{{- printf "http://%s-falcosidekick:%s" $falcoName $listenPort -}}
	{{- end -}}

(http://falco-falcosidekick:2801 > http://falco-falcosidekick.falco.svc.cluster.local:2801 when it's enabled)

[Issif]

I see, feel free to propose a PR to add the setting when gvisor is enabled. Thanks