Blog: Introducing Falco Operator 0.2.0

Dear Falco Community, today we are excited to announce the release of Falco Operator 0.2.0, the first production-ready release of the Kubernetes operator for Falco!

Since the technical preview announced with Falco 0.41.0, we have been working hard to make the operator robust, extensible, and ready for real-world environments. This release brings a redesigned API, a new Component controller for managing the Falco ecosystem, new artifact management capabilities, enhanced observability, and a significantly improved operational model, all grounded in Kubernetes-native patterns.

We merged 58 commits since v0.1.1, delivering major new features, 10 bug fixes, and comprehensive architectural improvements. Thank you to all our contributors and the community for your feedback along the way!

Going forward, the Falco Operator is the recommended way to deploy and manage Falco on Kubernetes. While the existing Helm chart remains fully supported, we plan to transition to the operator as the standard deployment method. More details on the transition timeline will follow in a future announcement.

To learn everything about the changes, read on!

What's new? TL;DR

Key features:

• Ecosystem components - deploy Falcosidekick, Falcosidekick UI, and k8s-metacollector as managed components
• ConfigMap support for rules and configuration, alongside OCI artifacts and inline definitions
• Structured API types for inline rules and configuration - YAML objects instead of strings
• Redesigned OCI artifact API with separate image and registry configuration
• Reference tracking with finalizers to prevent accidental deletion of Secrets and ConfigMaps
• Enhanced observability with Kubernetes events and status conditions across all controllers
• Update strategy support for DaemonSet and Deployment modes
• Server-Side Apply migration for safer, conflict-free reconciliation

Key fixes:

• Plugin initConfig now supports nested configuration objects
• RBAC compatibility with Kubernetes 1.32+
• Spurious update prevention via managed fields comparison
• Correct event recording with node-level attribution

The road to production readiness

When we introduced the Falco Operator as a technical preview in Falco 0.41.0, the vision was clear: provide a Kubernetes-native way to deploy and manage Falco that goes beyond what Helm charts and static manifests can offer. Since then, every aspect of the operator has been refined.

The reconciliation logic now uses Server-Side Apply for conflict-free updates. Status conditions follow Kubernetes conventions (Programmed, ResolvedRefs, Available, Reconciled) so that standard tooling and dashboards can monitor operator health out of the box. Finalizers protect referenced resources from accidental deletion. And the new Component controller lays the groundwork for managing the entire Falco ecosystem from a single operator.

Version 0.2.0 is the result of this effort, a release we are confident in for production environments.

Major features and improvements

Ecosystem components

The new Component custom resource (instance.falcosecurity.dev/v1alpha1) enables the operator to deploy and manage the full Falco ecosystem from a single control plane. Three component types are supported:

Deploying Falcosidekick is as simple as:

apiVersion: instance.falcosecurity.dev/v1alpha1
kind: Component
metadata:
 name: sidekick
spec:
 component:
 type: falcosidekick
 replicas: 2

The operator handles the Deployment, Service, ServiceAccount, and RBAC automatically. Each component type ships with production-ready defaults (health probes, security context, resource profiles) that can be fully customized via podTemplateSpec.

For Falcosidekick UI, note that an external Redis instance is required. If Redis is not available, the pod stays in Init:0/1 state, the built-in wait-redis init container blocks until Redis is reachable. See the component documentation for setup examples including a bundled Redis StatefulSet.

As part of this work, the internal controller structure was reorganized under controllers/instance/ with shared reconciliation logic extracted into reusable packages, improving maintainability and consistency across all instance-level controllers.

ConfigMap support for rules and configuration

Rulesfile and Config resources can now source their content from Kubernetes ConfigMaps, in addition to OCI artifacts and inline definitions. This provides a familiar, Git-friendly workflow for teams that manage configuration through standard Kubernetes tooling.

Rulesfile from a ConfigMap:

apiVersion: artifact.falcosecurity.dev/v1alpha1
kind: Rulesfile
metadata:
 name: custom-rules
spec:
 configMapRef:
 name: my-rules-configmap
 priority: 50

Config from a ConfigMap:

apiVersion: artifact.falcosecurity.dev/v1alpha1
kind: Config
metadata:
 name: custom-config
spec:
 configMapRef:
 name: my-config-configmap
 priority: 50

The referenced ConfigMap must contain the content under a key named rules.yaml (for Rulesfile) or config.yaml (for Config). All three sources (OCI, inline, and ConfigMap) can be combined in a single resource when needed.

Structured API types

The inlineRules field in the Rulesfile CRD and the config field in the Config CRD are now structured YAML objects instead of plain strings. This enables proper validation, better editor support, and eliminates the need for YAML-in-YAML escaping.

Before (v0.1.x):

spec:
 config: |-
 engine:
 kind: modern_ebpf

After (v0.2.0):

spec:
 config:
 engine:
 kind: modern_ebpf

The same applies to inlineRules: rules are now defined as structured YAML lists rather than pipe-literal strings.

Redesigned OCI artifact API

The OCI artifact reference model has been completely redesigned for clarity and extensibility. The previous flat reference and pullSecret fields are replaced with a structured image and registry model.

Before (v0.1.x):

spec:
 ociArtifact:
 reference: ghcr.io/falcosecurity/rules/falco-rules:latest
 pullSecret:
 secretName: my-secret

After (v0.2.0):

spec:
 ociArtifact:
 image:
 repository: falcosecurity/rules/falco-rules
 tag: latest
 registry:
 name: ghcr.io
 auth:
 secretRef:
 name: my-secret

This separation makes the API more explicit and enables per-registry TLS configuration, plain HTTP support, and a consistent credential model. See the migration guide for details on updating your resources.

Reference tracking with finalizers

The operator now adds finalizers to Secrets and ConfigMaps that are referenced by artifact resources. This prevents accidental deletion of credentials or configuration data that would break Falco deployments. When a referenced resource is deleted, the operator blocks the deletion until all referencing artifacts are updated or removed.

Enhanced observability

All controllers now emit Kubernetes events for significant operations: artifact creation, updates, removals, and priority changes. Events include the node name for artifact controllers, making it straightforward to trace which operations happened on which nodes.

Status conditions have been overhauled to follow Kubernetes conventions:

• Artifact resources report Programmed (whether the artifact is successfully applied) and ResolvedRefs (whether referenced ConfigMaps/Secrets exist)
• Falco instances report Reconciled and Available
• All artifact CRDs now include printcolumns for readable kubectl get output

Update strategy support

The Falco CRD now accepts update strategy configuration for both deployment modes:

# DaemonSet mode
spec:
 type: DaemonSet
 updateStrategy:
 type: RollingUpdate
 rollingUpdate:
 maxUnavailable: 1

# Deployment mode
spec:
 type: Deployment
 strategy:
 type: RollingUpdate
 rollingUpdate:
 maxUnavailable: 1
 maxSurge: 1

Server-Side Apply

Under the hood, the operator has migrated from the dry-run/update pattern to Server-Side Apply (SSA) for all reconciliation operations. This brings:

• Conflict detection: concurrent modifications to managed fields are detected and reported
• Ownership tracking: the operator only manages fields it owns, leaving user-applied changes intact
• Reduced spurious updates: managed fields comparison prevents unnecessary API calls

Breaking changes ⚠️

Version 0.2.0 includes several API breaking changes. All existing custom resources must be updated before upgrading. A detailed migration guide is available in the repository documentation.

Summary of breaking changes

After upgrading, re-apply all CRDs and update your custom resources following the migration guide. The operator will reconcile the new format automatically.

A Helm chart is on its way

We are currently developing a Helm chart for installing the Falco Operator itself, which will simplify deployment and configuration of the operator in production environments. Stay tuned for the announcement.

Meet us at KubeCon

We will be talking about the Falco Operator during the maintainer track at the upcoming KubeCon. If you are interested in learning more, asking questions, or sharing feedback, come find us at the CNCF Falco kiosk, we would love to chat!

Try it out

Install the operator:

VERSION=latest
if [ "$VERSION" = "latest" ]; then
 kubectl apply --server-side -f https://github.com/falcosecurity/falco-operator/releases/latest/download/install.yaml
else
 kubectl apply --server-side -f https://github.com/falcosecurity/falco-operator/releases/download/${VERSION}/install.yaml
fi

Then choose how you want to get started:

Full stack quickstart

Deploy the entire Falco ecosystem in the falco namespace with one command:

VERSION=latest
if [ "$VERSION" = "latest" ]; then
 kubectl apply --server-side -f https://github.com/falcosecurity/falco-operator/releases/latest/download/quickstart.yaml
else
 kubectl apply --server-side -f https://github.com/falcosecurity/falco-operator/releases/download/${VERSION}/quickstart.yaml
fi

This deploys Falco, container and k8smeta plugins, detection rules, Falcosidekick, Falcosidekick UI with Redis, and k8s-metacollector - all pre-wired.

Verify:

kubectl get falco,plugins,rulesfiles,configs,components -n falco
kubectl get pods -n falco

Step by step

Deploy Falco:

cat <<EOF | kubectl apply -f -
apiVersion: instance.falcosecurity.dev/v1alpha1
kind: Falco
metadata:
 name: falco
spec: {}
EOF

Add the container plugin (required by the official rules for container metadata fields):

cat <<EOF | kubectl apply -f -
apiVersion: artifact.falcosecurity.dev/v1alpha1
kind: Plugin
metadata:
 name: container
spec:
 ociArtifact:
 image:
 repository: falcosecurity/plugins/plugin/container
 tag: latest
 registry:
 name: ghcr.io
EOF

And add detection rules:

cat <<EOF | kubectl apply -f -
apiVersion: artifact.falcosecurity.dev/v1alpha1
kind: Rulesfile
metadata:
 name: falco-rules
spec:
 ociArtifact:
 image:
 repository: falcosecurity/rules/falco-rules
 tag: latest
 registry:
 name: ghcr.io
 priority: 50
EOF

Optionally, add Falcosidekick to route events to your favorite integrations:

cat <<EOF | kubectl apply -f -
apiVersion: instance.falcosecurity.dev/v1alpha1
kind: Component
metadata:
 name: sidekick
spec:
 component:
 type: falcosidekick
 replicas: 2
EOF

For the complete documentation, including the CRD reference, configuration options, and architecture overview, visit the Falco Operator repository and the operator setup guide.

Stay connected

Join us on social media and in our community calls! It's always great to have new members in the community, and we're looking forward to hearing your feedback and ideas.

You can find all the most up-to-date information at https://falco.org/community/.