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:
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 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, will try to keep thing 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 👍.
A brief explanation of parameters:
config.kubeless.namespace
: is the namespace where ourKubeless
will runconfig.kubeless.function
: is the name of ourKubeless function
That's it, we really tried to get a nice UX 😉.
Install our Kubeless function
We'll not explain how to write or how work Kubeless
functions, please read the official docs for more information.
Our really 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:
Here we are, after a few moments, we have a Kubeless
function running in namespace kubeless and that can be triggered by its service delete-pod on port 8080:
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, if 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 really 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 also 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