Follow CLI args standards in Falco

[incertum]

Proposing to follow common and standard Program Argument Syntax Conventions for Falco's CLI options, for example see this resource. For example -pk and similar options seem to fall outside of these conventions.

[GLVSKiriti]

@Andreagit97 @incertum I am interested in this issue!
Can I work on this?

[Andreagit97]

Not clear to me what was the plan @incertum had in mind when she opened this issue, so I'll let her answer here.
My 2 cents, this issue seems related to possible breaking changes in the Falco UX, maybe something that we want to tackle for Falco 1.0.0, not sure this is a "good first issue" but let's see what others think about that

[incertum]

Goal is to correct the -pc, -pk or -pcontainer, -pkubernetes flags that do not conform to standard CLI practices. Usually -pc implies a combination of -p and -c.

https://falco.org/docs/outputs/formatting/

falco/userspace/falco/app/options.cpp

Line 187 in 99781f7

("p,print", "Print (or replace) additional information in the rule's output.\nUse -pc or -pcontainer to append container details.\nUse -pk or -pkubernetes to add both container and Kubernetes details.\nIf using gVisor, choose -pcg or -pkg variants (or -pcontainer-gvisor and -pkubernetes-gvisor, respectively).\nIf a rule's output contains %container.info, it will be replaced with the corresponding details. Otherwise, these details will be directly appended to the rule's output.\nAlternatively, use -p <output_format> for a custom format. In this case, the given <output_format> will be appended to the rule's output without any replacement.", cxxopts::value(print_additional), "<output_format>")

I would propose them being:

• -pc -> --print-container and --print-container-gvisor or similar
• -pk -> --print-kubernetes and --print-kubernetes-gvisor or similar

Suggesting to sync with @leogr.

[leogr]

Usually -pc implies a combination of -p and -c.

This is the main issue, likely.

If we follow POSIX's recommendation:

Multiple options may follow a hyphen delimiter in a single token if the options do not take arguments. Thus, ‘-abc’ is equivalent to ‘-a -b -c’.

So, -pc is not ok.

But:

An option and its argument may or may not appear as separate tokens. (In other words, the whitespace separating them is optional.) Thus, -o foo and -ofoo are equivalent.

So -pcontainer is equivalent to -p container and it would be ok (and it is what's happening here).

My recommendation is to reaudit all flags, and try to make them consistent with POSIX.
The cobra project may be a source of inspiration. Also, if we follow Cobra/posix recommendations, we will have consistency across all our other tools (which are implemented in Go).

Let's dig deeper into this once we have found some time.

[incertum]

Agreed @leogr let's investigate more. It's something valuable for Falco 1.x.

[LucaGuerra]

/milestone 1.0.0

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale

[leogr]

/assign @LucaGuerra

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale

@LucaGuerra as privately discussed we are close to finish this, keep as posted 🙏

[leogr]

@LucaGuerra this may be interesting for the -o syntax
https://docs.helm.sh/docs/intro/using_helm/#the-format-and-limitations-of---set

[LucaGuerra]

So these are the potential issues that I see:

• We introduced the possibility of adding a comma , in some options, such as -o field={"opt1": "val1", "opt2": "val2"} this is not technically compliant because according to the recommendations -o a=b,c should be the same as -o a=b -o c. I think it's convenient to have commas so it's fine if we do not follow the recommendations there. Anyone disagrees?
• -pk and friends should go away in 1.x . In order to do this we need two separate things:
  • get rid of %container.info in the rules OR have a different way of specifying it. Note that without the effect of -pk/-pc it will become a syntax error in the rules so it will break existing behavior.
  • convert all -pk/-pc usage into appropriate configuration options or CLI flags, which we basically can already do.

[leogr]

So these are the potential issues that I see:

• We introduced the possibility of adding a comma , in some options, such as -o field={"opt1": "val1", "opt2": "val2"} this is not technically compliant because according to the recommendations -o a=b,c should be the same as -o a=b -o c. I think it's convenient to have commas so it's fine if we do not follow the recommendations there. Anyone disagrees?

I believe the examples you provided can't be correlated because of a missing detail. AFAIK, the recommendation does not allow spaces in the option's value. This is particularly relevant when commas are involved.
For example, while -o a=b,c is equivalent to -o a=b -o c, -o a=b, c (note the space after the command) is not and should be considered as a="b, c" (or not allowed). Likewise, -o field={"opt1": "val1", "opt2": "val2"} may be compliant (because of the space after the comma), whereas -o field={"opt1": "val1","opt2": "val2"} is not for sure.

Helm --set command fully supports this (perhaps just by chance) as per their examples 👇

Lists can be expressed by enclosing values in { and }. For example, --set name={a, b, c} translates to:

name:
  - a
  - b
  - c

and

Multiple values can be set this way. The line --set servers[0].port=80,servers[0].host=example becomes:

servers:
  - port: 80
    host: example

So, in the end, I totally agree to support -o field={"opt1": "val1", "opt2": "val2"} (with the space after the comma), but I'm not fully convinced of the general case yet. I believe we should dig more into this and make the whole configuration system more solid.

Furthermore, what about the escaping? For example, do we support something like Helm's --set nodeSelector."kubernetes\.io/role"=master ?

• -pk and friends should go away in 1.x . In order to do this we need two separate things:

  • get rid of %container.info in the rules OR have a different way of specifying it. Note that without the effect of -pk/-pc it will become a syntax error in the rules so it will break existing behavior.
  • convert all -pk/-pc usage into appropriate configuration options or CLI flags, which we basically can already do.

I'm in favor of getting rid of both -p* and %container.info in 1.x.