
Kubernetes Response Engine, Part 7: Falcosidekick + Cloud Functions
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 6 : Falcosidekick + Cloud Run
Earlier in this series, we have seen how to use Argo, Tekton, and Knative to trigger a resource after getting input from Falcosidekick. Recently, Falcosidekick received a new output type support for Cloud Functions.
In this part, let us learn how we can use Falcosidekick and Cloud Functions to detect and delete a compromised pod.
We will not go through what Cloud Functions is in-depth, however, you can always find a good overview about it in the official documentation.
Here is the high-level overview architecture that shows what we want to achieve at the end of the day:
You can find all the related code and resources in this repository.
Prerequisites
- gcloud 342.0.0
- kubectl 1.20.5
Tutorial
Provision Google Kubernetes Engine (GKE) Cluster
As the blog title said already, we need to create a GKE cluster with workload identity enabled:
Configure IAM Service Accounts
We need to create a new Service Account for target $GOOGLE_PROJECT_ID
using IAM Binding policies to get access our Cloud Function:
In the beginning, we already enabled WorkloadIdentity feature for our GKE Cluster by setting --workload-pool
flag. What we need to do here is to add a iam.workloadIdentityUser
role for the given Service Account.
We need to annotate the falco-falcosidekick
resource. So it can grant access for our Cluster. Set up the Falcosidekick SA to impersonate a GCP SA:
Create Necessary Cluster Role
To limit function role access in the particular cluster, ensure that only SA has limited permissions within a particular namespace by using Role Bindings.
To obtain the Token from secret, we need to get pod-deleter
ServiceAccount resource first:
Add the pod-destroyer
user to your KUBECONFIG:
We can test it with auth can-i to check if roles are set correctly
Create Secret Manager
The main reason Secret Manager get involved our architecture is because we had to find a way out to initialize our kubeclient in our function by getting pod-destroyer
's KUBECONFIG.
We need to create a new secrets IAM policy for the SA member to enable Managing Secrets:
Create a new secret, called pod-destroyer
:
Push the our generated kubeconfig_pod-destroyer.yaml
file as a new version:
Finally, we are ready to deploy our Cloud Run function!
Deploy Google Cloud Function
In this demonstration our function will simply delete the pwned Pod, as we already pointed it out in the architecture diagram.
- The Go code
If you rather see it in GitHub.
We need to pass extra --service-account
flag in order to get access to Secret Manager.
Deploy the function:
Now, get the name of the function:
Install Falco + Falcosidekick
It is time to install Falco
, Falcosidekick
with Cloud Function
output type enabled:
Test
Try to run a busybox image and execute a command:
Try to exec into:
We can check the logs of the 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 Open Source world. Of course, it's just the beginning, feel free to share your functions and workflows with the community for starting the creation of a true 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.