
Kubernetes Response Engine, Part 6: Falcosidekick + Cloud Run
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 1 : Falcosidekick + Kubeless
- 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 7: Falcosidekick + Cloud Functions
Recently, we added two new output-type support to Falcosidekick, and they are Cloud Functions, and Cloud Run. This blog post will discuss how to set up Kubernetes Response Engine on GKE (Google Kubernetes Engine) by using Cloud Run.
Let's start by explaining a little bit about Cloud Run. Cloud Run
is a managed compute platform that enables you to run containers that are invocable via requests or events. Cloud Run
is serverless: it abstracts away all infrastructure management, so you can focus on what matters most — building great applications.
For more information, see Cloud Run.
Given below is a reference architecture of what's being explained in this blog.
This demo might be useful for Google Cloud users who might already be using GKE with Falco
to protect container runtime against malicious behaviors, and wants to take any action for them with Cloud Run
.
Table of Contents
Prerequisites
- gcloud 342.0.0
- ko 0.8.3
Tutorial
Provision GKE (Google Kubernetes Engine) Cluster
First, let us create a GKE cluster.
To learn more about the setup GKE Cluster, see quickstart guide.
Deploy Cloud Run Function
Once GKE is set up, we are ready to deploy Cloud Run. But before doing that, let us examine the responsibility of the Cloud Run function. As you can see in the reference architecture, this function will delete the pwned pods. To be able to do that, Cloud Run should be given appropriate permissions.
There are two approaches to obtain these permissions.
- The first approach is creating a Kubernetes Service Account, an appropriate Role with granted permissions to delete pod resource, and a RoleBinding to bind Role to Service Account. Then create the kubeconfig file, package it up with the function code while deploying the Cloud Run function, and use this file to create a Kubernetes client.
To learn more about the kubeconfig files, see kubeconfig.
- The second approach is producing a valid ~/.kube/config with a library called google.golang.org/api/ within the function code. We are doing this because the representation of the valid ~/.kube/config file is clientcmd/api/Config in Go.
We'll go with the second approach in this demo. Thanks to Scott Blum and his detailed blog post on this topic. I highly recommend that you check that out.
Let's deploy the function. If you want to take a look at the function code, see the repository.
Note that we're going to use the ko tool to build and push our container image which is created by Google. ko is a simple and fast container image builder for Go applications.
To learn more, see the official repository of the project.
We are also going to use Container Registry as an image repository service provided by the Google Cloud to store, manage, and secure your Docker container images. Alternatively, you can also use DockerHub, quay.io, etc.
Install Falco + Falcosidekick
Now, it is time to set up Falco
, Falcosidekick
with the Cloud Run
output type enabled.
Check the logs to see if Cloud Run
output enabled for Falcosidekick.
If you see the GCPCloudRun in the list of enabled outputs, you can confirm that everything is working as expected 👍.
Test
Let us start by creating a test pod:
Let's run a shell command inside and see what happens:
As expected the command returned the output. However, the status of the pod we retrieved is Terminating as follows:
To investigate further, check the logs of the Cloud Run function from the Google Cloud Console:
Let us check the logs of Falco and Falcosidekick to see what happened.
For Falcosidekick
:
Conclusion
We got another way to create a Response Engine with amazing pieces of software from the Open Source world. Of course, it's just the beginning, feel free to share your functions and workflows with the community for creating a library of remediation methods.
If you would like to find out more about Falco:
- Get started in Falco.org.
- Check out the Falco project in GitHub.
- Get involved in the Falco community.
- Meet the maintainers on the Falco Slack.
- Follow @falco_org on Twitter.