
Kubernetes Response Engine, Part 1: Falcosidekick + Kubeless
This blog post is part of a series of articles about how to create a
Kubernetes
response engine withFalco
,Falcosidekick
and aFaaS
.See other posts:
- Kubernetes Response Engine, Part 2 : Falcosidekick + OpenFaas
- Kubernetes Response Engine, Part 3 : Falcosidekick + Knative
- Kubernetes Response Engine, Part 4 : Falcosidekick + Tekton
- Kubernetes Response Engine, Part 5 : Falcosidekick + Argo
- Kubernetes Response Engine, Part 6 : Falcosidekick + Cloud Run
- Kubernetes Response Engine, Part 7: Falcosidekick + Cloud Functions
Two years ago, we presented to you a Kubernetes Response Engine
based on Falco
. The idea was to trigger Kubeless
serverless functions for deleting infected pod, start a Sysdig
capture or forward the events
to GCP PubSub
. See the README.
To avoid maintaining this custom stack, we worked hard with the community to integrate all components into Falcosidekick
and to improve the UX.
With the last release 2.20.0
we have the finale piece, the integration of Kubeless
as native output. More details in our retrospective of 2020.
In this blog post, we will explain the basic concepts for integrating your own Response Engine into K8S with the stack Falco
+ Falcosidekick
+ Kubeless
.
Requirements
We require a kubernetes
cluster running at least 1.17
release and helm
and kubectl
installed.
Install Kubeless
Follow the official quick start page:
After a few seconds, we can check that the controller is up and running:
Install Falco
Firstly, we'll create the namespace that will use both Falco
and Falcosidekick
:
Add the helm
repo:
In a real project, you should get the whole chart with helm pull falcosecurity/falco --untar
and then configure the values.yaml
. For this tutorial, we will try to keep things as easy as possible and set configs directly by helm install
command:
You should get this output:
And you can see your new Falco
pods:
The arguments --set falco.jsonOutput=true --set falco.httpOutput.enabled=true --set falco.httpOutput.url=http://falcosidekick:2801
are there configuring the format of events and the URL where Falco
will send them. As Falco
and Falcosidekick
will be in the same namespace, we can directly use the name of the service (falcosidekick
).
Install Falcosidekick
The process is quite the same:
You should get this output:
We check the logs:
Kubeless
is displayed as enabled output, everything is good 👍.
That's it, we really tried to get a nice UX 😉.
Install our Kubeless function
We'll not explain how to write or how to work Kubeless
functions, please read the official docs for more information.
Our basic function will receive events from Falco
, thanks to Falcosidekick
. Check if the triggered rule is Terminal Shell in container. See rule, extract the namespace and pod name from fields of events, and delete the according pod:
Basically, the process is:
Before deploying our function, we need to create a ServiceAccount
for it, as it will need the right to delete a pod in any namespace:
Only remains the installation of our function itself:
Test our function
We start by creating a dumb pod:
Let's run a shell command inside and see what happens:
As expected, we got the result of our command, but, to get the status of the pod now:
💥 It has been terminated 💥
We can now check the logs of components.
For Falco
:
For Falcosidekick
:
(Notice, the function returns nothing, this is why the message log is empty)
For delete-pod
function:
Conclusion
With this simple example, we only scratched the surface of possibilities. Everything is possible now, so don't hesitate to share with us on Slack (https://kubernetes.slack.com #falco) your comments, ideas and successes. You're always welcome to contribute.
Bonus: You're running Falcosidekick
outside Kubernetes
but still want to use the Kubeless
output? No problem, you can declare a kubeconfig file to use. See README.
Bonus 2: For people who wants to use Knative
in place of Kubeless
, it's coming soon 😉
Enjoy