The driver
section has been reworked based on the following PR: falcosecurity/falco#2413.
It is an attempt to uniform how a driver is configured in Falco.
It also groups the configuration based on the driver type.
Some of the drivers has been renamed:
- kernel modules has been renamed from
module
tokmod
; - the ebpf probe has not been changed. It's still
ebpf
; - the modern ebpf probe has been renamed from
modern-bpf
tomodern_ebpf
.
The gvisor
configuration has been moved under the driver
section since it is considered a driver on its own.
The old Kubernetes client has been removed in Falco 0.37.0. For more info checkout this issue: falcosecurity/falco#2973 (comment). The k8s-metacollector and k8s-meta substitute the old implementation.
The following resources needed by Falco to connect to the API server are no longer needed and has been removed from the chart:
- service account;
- cluster role;
- cluster role binding.
When the collectors.kubernetes
is enabled the chart deploys the k8s-metacollector and configures Falco to load the
k8s-meta plugin.
By default, the collectors.kubernetes.enabled
is off; for more info, see the following issue: falcosecurity/falco#2995.
The Falco docker image does not ship anymore the plugins: falcosecurity/falco#2997.
For this reason, the resolveDeps
is now enabled in relevant values files (ie. values-k8saudit.yaml
).
When installing rulesfile
artifacts falcoctl
will try to resolve its dependencies and install the required plugins.
The new chart deploys new k8s resources and new configuration variables have been added to the values.yaml
file. People upgrading the chart from v2.x.y
have to port their configuration variables to the new values.yaml
file used by the v3.0.0
chart.
If you still want to use the old values, because you do not want to take advantage of the new and shiny falcoctl tool then just run:
helm upgrade falco falcosecurity/falco \
--namespace=falco \
--reuse-values \
--set falcoctl.artifact.install.enabled=false \
--set falcoctl.artifact.follow.enabled=false
This way you will upgrade Falco to v0.34.0
.
NOTE: The new version of Falco itself, installed by the chart, does not introduce breaking changes. You can port your previous Falco configuration to the new values.yaml
by copy-pasting it.
Falcoctl is a new tool born to automatize operations when deploying Falco.
Before the v3.0.0
of the charts rulesfiles and plugins were shipped bundled in the Falco docker image. It precluded the possibility to update the rulesfiles and plugins until a new version of Falco was released. Operators had to manually update the *rulesfiles or add new plugins to Falco. The process was cumbersome and error-prone. Operators had to create their own Falco docker images with the new plugins baked into it or wait for a new Falco release.
Starting from the v3.0.0
chart release, we add support for falcoctl in the charts. By deploying it alongside Falco it allows to:
- install artifacts of the Falco ecosystem (i.e plugins and rules at the moment of writing)
- follow those artifacts(only rulesfile artifacts are recommended), to keep them up-to-date with the latest releases of the Falcosecurity organization. This allows, for instance, to update rules detecting new vulnerabilities or security issues without the need to redeploy Falco.
The chart deploys falcoctl using an init container and/or sidecar container. The first one is used to install artifacts and make them available to Falco at start-up time, the latter runs alongside Falco and updates the local artifacts when new updates are detected.
Based on your deployment scenario:
-
Falco without plugins and you just want to upgrade to the new Falco version:
helm upgrade falco falcosecurity/falco \ --namespace=falco \ --reuse-values \ --set falcoctl.artifact.install.enabled=false \ --set falcoctl.artifact.follow.enabled=false
When upgrading an existing release, helm uses the new chart version. Since we added new template files and changed the values schema(added new parameters) we explicitly disable the falcoctl tool. By doing so, the command will reuse the existing configuration but will deploy Falco version
0.34.0
-
Falco without plugins and you want to automatically get new falco-rules as soon as they are released:
helm upgrade falco falcosecurity/falco \ --namespace=falco \
Helm first applies the values coming from the new chart version, then overrides them using the values of the previous release. The outcome is a new release of Falco that:
- uses the previous configuration;
- runs Falco version
0.34.0
; - uses falcoctl to install and automatically update the falco-rules;
- checks for new updates every 6h (default value).
-
Falco with plugins and you want just to upgrade Falco:
helm upgrade falco falcosecurity/falco \ --namespace=falco \ --reuse-values \ --set falcoctl.artifact.install.enabled=false \ --set falcoctl.artifact.follow.enabled=false
Very similar to scenario
1.
-
Falco with plugins and you want to use falcoctl to download the plugins' rulesfiles:
- Save falcoctl configuration to file:
cat << EOF > ./falcoctl-values.yaml #################### # falcoctl config # #################### falcoctl: image: # -- The image pull policy. pullPolicy: IfNotPresent # -- The image registry to pull from. registry: docker.io # -- The image repository to pull from. repository: falcosecurity/falcoctl # -- Overrides the image tag whose default is the chart appVersion. tag: "main" artifact: # -- Runs "falcoctl artifact install" command as an init container. It is used to install artfacts before # Falco starts. It provides them to Falco by using an emptyDir volume. install: enabled: true # -- Extra environment variables that will be pass onto falcoctl-artifact-install init container. env: {} # -- Arguments to pass to the falcoctl-artifact-install init container. args: ["--verbose"] # -- Resources requests and limits for the falcoctl-artifact-install init container. resources: {} # -- Security context for the falcoctl init container. securityContext: {} # -- Runs "falcoctl artifact follow" command as a sidecar container. It is used to automatically check for # updates given a list of artifacts. If an update is found it downloads and installs it in a shared folder (emptyDir) # that is accessible by Falco. Rulesfiles are automatically detected and loaded by Falco once they are installed in the # correct folder by falcoctl. To prevent new versions of artifacts from breaking Falco, the tool checks if it is compatible # with the running version of Falco before installing it. follow: enabled: true # -- Extra environment variables that will be pass onto falcoctl-artifact-follow sidecar container. env: {} # -- Arguments to pass to the falcoctl-artifact-follow sidecar container. args: ["--verbose"] # -- Resources requests and limits for the falcoctl-artifact-follow sidecar container. resources: {} # -- Security context for the falcoctl-artifact-follow sidecar container. securityContext: {} # -- Configuration file of the falcoctl tool. It is saved in a configmap and mounted on the falcotl containers. config: # -- List of indexes that falcoctl downloads and uses to locate and download artiafcts. For more info see: # https://github.com/falcosecurity/falcoctl/blob/main/proposals/20220916-rules-and-plugin-distribution.md#index-file-overview indexes: - name: falcosecurity url: https://falcosecurity.github.io/falcoctl/index.yaml # -- Configuration used by the artifact commands. artifact: # -- List of artifact types that falcoctl will handle. If the configured refs resolves to an artifact whose type is not contained # in the list it will refuse to downloade and install that artifact. allowedTypes: - rulesfile install: # -- Do not resolve the depenencies for artifacts. By default is true, but for our use carse we disable it. resolveDeps: false # -- List of artifacts to be installed by the falcoctl init container. refs: [k8saudit-rules:0.5] # -- Directory where the *rulesfiles* are saved. The path is relative to the container, which in this case is an emptyDir # mounted also by the Falco pod. rulesfilesDir: /rulesfiles # -- Same as the one above but for the artifacts. pluginsDir: /plugins follow: # -- List of artifacts to be installed by the falcoctl init container. refs: [k8saudit-rules:0.5] # -- Directory where the *rulesfiles* are saved. The path is relative to the container, which in this case is an emptyDir # mounted also by the Falco pod. rulesfilesDir: /rulesfiles # -- Same as the one above but for the artifacts. pluginsDir: /plugins EOF
- Set
falcoctl.artifact.install.enabled=true
to install rulesfiles of the loaded plugins. Configure falcoctl to install the rulesfiles of the plugins you are loading with Falco. For example, if you are loading k8saudit plugin then you need to setfalcoctl.config.artifact.install.refs=[k8saudit-rules:0.5]
. When Falco is deployed the falcoctl init container will download the specified artifacts based on their tag. - Set
falcoctl.artifact.follow.enabled=true
to keep updated rulesfiles of the loaded plugins. - Proceed to upgrade your Falco release by running:
helm upgrade falco falcosecurity/falco \ --namespace=falco \ --reuse-values \ --values=./falcoctl-values.yaml
- Save falcoctl configuration to file:
-
Falco with multiple sources enabled (syscalls + plugins):
- Upgrading Falco to the new version:
helm upgrade falco falcosecurity/falco \ --namespace=falco \ --reuse-values \ --set falcoctl.artifact.install.enabled=false \ --set falcoctl.artifact.follow.enabled=false
- Upgrading Falco and leveraging falcoctl for rules and plugins. Refer to point 4. for falcoctl configuration.
- Upgrading Falco to the new version:
Starting from v0.3.0
, the chart drops the bundled rulesfiles. The previous version was used to create a configmap containing the following rulesfiles:
- application_rules.yaml
- aws_cloudtrail_rules.yaml
- falco_rules.local.yaml
- falco_rules.yaml
- k8s_audit_rules.yaml
The reason why we are dropping them is pretty simple, the files are already shipped within the Falco image and do not apport any benefit. On the other hand, we had to manually update those files for each Falco release.
For users out there, do not worry, we have you covered. As said before the rulesfiles are already shipped inside the Falco image. Still, this solution has some drawbacks such as users having to wait for the next releases of Falco to get the latest version of those rulesfiles. Or they could manually update them by using the [custom rules](. /README.md#loading-custom-rules).
We came up with a better solution and that is falcoctl. Users can configure the falcoctl tool to fetch and install the latest rulesfiles as provided by the falcosecurity organization. For more info, please check the falcoctl section.
NOTE: if any user (wrongly) used to customize those files before deploying Falco please switch to using the custom rules.
Starting from version v2.0.0
of the chart thefalcosecurity/falco-no-driver
is the default image. We were still supporting the falcosecurity/falco
image in v2.0.0
. But in v2.2.0
we broke the chart when using the falcosecurity/falco
image. For more info please check out the following issue: falcosecurity#419
There is only one switch to enable/disable the driver-loader init container: driver.loader.enabled=true. This simplification comes as a direct consequence of dropping support for the falcosecurity/falco
image. For more info: falcosecurity#418