Install and manage Falco via operator in Kubernetes

[krisnova]

Currently we have the falco operator. This operator does NOT install Falco in Kubernetes, but rather manages Falco rules based on CRDs. Debatably this repository could be renamed something like falco-rules-operator.

We have outlined various ways to Install Falco with Kubernetes in the official documentation.

In all of these examples there is a common theme. The theme is that

Falco is configurable, and each environment will require a different configuration. Furthermore that the installation story stops once Falco is running.

I believe this is a fundamental problem for all software, Falco included.

In order to provide users with a dynamic and logical installation method, we will need to encapsulate the installation method with software. Furthermore, if we want to support the installation over time we will need the same software to ensure the original state remains true.

This is where operators enter.

---

Can we please consider building a piece of software that has the following responsibilities

• Detecting the constraints of the environment which is running the software
• Making a decision on the best way to install Falco given those constraints
• Securely installing Falco with Kubernetes
• Ensures the state of Falco over time

There are a number of tools and patterns available to help with this effort. I have the most experience with kubebuilder and it worked well for me in the past. I am very interested in finding out more about Flux if anyone has any experience reports to share.

• Helm Chart Operator - Openshift
• Operator SDK
• Kubebuilder
• Flux
• Flux Helm Operator

---

• Does anyone have any thoughts or suggestions about overall design patterns here?
• Should we use falcoctl?
• Should we use a framework of sorts?
• Should we leverage the helm chart?
• Should we use CRDs? If so -- what do they look like?

All feedback is welcome :smile_cat:

[airadier]

My 2 cents:

I never tried Flux, I only know Helm operator (a wrapper for Helm charts but using an operator) and Operator SDK.

If the target is just having an Operator (so Falco is available in Operator Hub, for example), then just wrapping the existing helm charts using Helm operator can be a fast option.

I think it would also be interesting exploring Application CRDs from the Application SIG group and using the CRDs from https://github.com/open-cluster-management to manage multi-cluster deployments. For example, Falco could be automatically deployed in multiple clusters that are managed by Red Hat Advanced Cluster Management or IBM CloudPak for Multicloud Management using these CRDs.

Probably, Helm or helm-operator could also cover the case of using specific Application / open-cluster-management CRDs too.

[jnach]

I'm used to doing these from scratch, but more recently there's been a nice Ansible wrapper to make things a lot more simple (in the way of actually creating an operator), thoughts on requirements below:

• Detecting the constraints of the environment which is running the software This is really only limited by the imagination and privilege level. More on the second part below..
• Making a decision on the best way to install Falco given those constraints I'm sure experience can be turned into business logic with relative ease, no problem
• Securely installing Falco with Kubernetes This merits a conversation. If you want a kernel module, by definition you need privilege. If you want security, you must limit privilege. I like to imagine a dotted line between hosts and the k8s scheduler layer, you should not pierce this if you can help it. There are a wave of products that are leaning on the Deamonset feature to distribute a host agent with root privs. Abuse of the scheduler? Maybe. This won't work on immutable infrastructure, which has been the new standard in the enterprise for almost a year with bleeding edge k8s products..
• Ensures the state of Falco over time Also fits the operator pattern well, should be easy.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Issues labeled "cncf", "roadmap" and "help wanted" will not be automatically closed. Please refer to a maintainer to get such label added if you think this should be kept open.