[TRACKING] Breaking changes in Falco 1.0.0

[Andreagit97]

This issue keeps track of all deprecated Falco features that will be removed in Falco 1.0.0:

• append in Falco rule is deprecated in favor of override (see update(rule_loader): deprecate the append flag in falco rules #2992)
• syntax like

  - rule: Write below etc
    enabled: false

  is deprecated in favor of override (see update(rule_loader): deprecate the append flag in falco rules #2992).

    - rule: Write below etc
      enabled: false
      override:
         enabled: replace

  Please note that the enabled key is only deprecated when used as an override! So a rule like this is perfectly legit:

  - rule: legit_rule
    desc: legit rule description
    condition: evt.type=open
    output: user=%user.name command=%proc.cmdline file=%fd.name
    priority: INFO
    enabled: false

[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

[Andreagit97]

/remove-lifecycle stale

[FedeDP]

#3162 deprecated old rules_file config key in favor of new rules_files.

[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]

Good candidate 👉 falcosecurity/libs#2057

[FedeDP]

I'd also revisit the systemd units; perhaps we could have Falco packaged per-driver, like falco.rpm (modern_ebpf), falco-kmod.rpm, falco-ebpf.rpm and falco-plugins.rpm ?

Also, we could drop the falco.service alias for falco-kmod (or add it to other units?).

cc @ekoops

Main idea could be to have a single template unit since now we can just have:

ExecStart=/usr/bin/falco -o engine.kind=%i

and then enable the unit like systemctl enable falco@ebpf.
We would lose permissions granularity though.

Another option would be to create a falco.path unit and let other units install themselves in that path.

[leogr]

I'd also revisit the systemd units; perhaps we could have Falco packaged per-driver, like falco.rpm (modern_ebpf), falco-kmod.rpm, falco-ebpf.rpm and falco-plugins.rpm ?

@FedeDP

I'd prefer to split the drivers into different packages. For example:

• falco.rpm (modern_ebpf built-in)
• falco-driver-kmod.rpm (optional package, just the kmod, overwrite the Falco unit, depends on falco.rpm and requires kernel headers)
• falco-driver-ebpf.rpm (optional package, just the legacy, overwrite the Falco unit, depends on falco.rpm and requires kernel headers)

Installing falco-driver-kmod.rpm and falco-driver-ebpf.rpm simultaneously should be disallowed.

[FedeDP]

Yep that is what i proposed :D

[leogr]

Yep that is what i proposed :D

Great. What I did not understand from your proposal is whether the driver package depends on the main package (or not).

[FedeDP]

That's a different story, i have no opinions on that. Either we could ship all packages like "full" packages with just minor differences (eg: falco.service unit would be configured and installed for the chosen driver only), or we could ship a default falco package with the executable and then the driver-flavored packages would install the rest with the needed deps (eg: falco-driver-kmod would install the falco-kmod systemd unit, the /usr/src/falco-... driver sources, would have the dkms and kernel headers deps, and so on)

[leogr]

That's my point. I'd avoid shipping all packages like full, since it seems to me not aligned with distro best practices. Moreover, the other solution should work better when uninstalling packages (since each package just tracks its own files, and does not overlap with files coming from other packages).

[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

[FedeDP]

/remove-lifecycle stale