fix dir mounting collision when both gRPC and nats are enabled

[leogr]

What type of PR is this?

/kind bug

/kind chart-release

Any specific area of the project related to this PR?

/area falco-chart

What this PR does / why we need it:

This PR fixes the duplicate /var/run/falco mounting problem (when both gRPC and nats are enabled) by prefixing mounting point inside the container with /host for the gRPC Unix socket path.
Note that at the host level the mounting point is still equal to one specified by the config (ie. without the /host prefix)

Which issue(s) this PR fixes:

Fixes #54

Special notes for your reviewer:

Checklist

• Chart Version bumped
• CHANGELOG.md updated

[poiana]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign leogr
You can assign the PR to them by writing /assign @leogr in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• falco/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[leogr]

/cc @nibalizer
PTAL

Could someone here help me in testing this PR with NATS enabled?

[nibalizer]

I can try to test this @leogr :)

[nibalizer]

This worked for me when I tested it. It brings up a couple questions:

1. Why is NATS support a special case now? The sidekick supports it (and a million other things) without a need for a emptydir/fifo or custom daemon or a docker image still in the sysding namespace. I think we could clean up the helm chart a bit by saying if you want nats use the sidekick.

2. The use of /host is I think maybe not the right choice. If we know the exporter or another grpc-unixsocket consumer will be deployed in the same pod as falco I think we could use emptydir. I don't think using the host's filesystem is a bad idea but using the specific path of (the host's) /var/run/falco doesn't seem right to me and assumes any consumer pod would mount in that directory. As a user I'd rather not mount in /var/run from my host if I didn't have to.

My request here is to move the path to something unique and unimportant on the base host or to use an emptyDir.

[leogr]

1. Why is NATS support a special case now? The sidekick supports it (and a million other things) without a need for a emptydir/fifo or custom daemon or a docker image still in the sysding namespace. I think we could clean up the helm chart a bit by saying if you want nats use the sidekick.

I totally agree, but unfortunately, I don't have any experience with NATS so I can't make a decision.
cc @fntlnz @leodido

2. The use of /host is I think maybe not the right choice. If we know the exporter or another grpc-unixsocket consumer will be deployed in the same pod as falco I think we could use emptydir. I don't think using the host's filesystem is a bad idea but using the specific path of (the host's) /var/run/falco doesn't seem right to me and assumes any consumer pod would mount in that directory. As a user I'd rather not mount in /var/run from my host if I didn't have to.

There're different issues here.

Regarding /host I can agree. I have chosen that path just because Falco is already mounting other host paths there. I know there's no formal convention about that, but it seems to be a de facto standard for Falco.

Secondly, since Falco can be installed either with a DaemonSet or in the host directly, /var/run/falco is the natural place a consumer should look for the Falco UnixSocket socket. Indeed, falco-exporter - that does NOT run the in the same pod since it's a different deployment - mounts /var/run/falco from the host for this reason.
That being said, I'm not sure this is the best approach, but it was natural to me because of the host installation use case.

My request here is to move the path to something unique and unimportant on the base host or to use an emptyDir.

I'd take a different strategy: if we could modify the NATS configuration to do not use /var/run/falco, then I will just leave the gRPC configuration as-is, and I will not merge this PR (mainly because of the host level use case).

But, can we modify the NATS?

[nibalizer]

I believe the NATS code in question is actually sysdig/falco code here. So we could modify that, yes.

[leogr]

I believe the NATS code in question is actually sysdig/falco code here. So we could modify that, yes.

I have to look into that.
cc @nestorsalceda

[leogr]

I have looked again into this and @nibalizer reasons are enough to close this PR