Falco – Getting Started

Docs: Try Falco with Docker

Mon, 01 Jan 0001 00:00:00 +0000

Install Falco

First, ensure you have a Linux machine with a recent version of Docker installed. Note that the following will not work on Windows or macOS running Docker Desktop.

Run the following command:

docker run --rm -it \
 --name falco \
 --privileged \
 -v /sys/kernel/tracing:/sys/kernel/tracing:ro \
 -v /var/run/docker.sock:/host/var/run/docker.sock \
 -v /proc:/host/proc:ro \
 -v /etc:/host/etc:ro \
 falcosecurity/falco:0.43.0

Falco is now monitoring your system using the pre-installed set of rules that alert you upon suspicious behavior.

Trigger a rule

Open another terminal on the same machine and run:

sudo cat /etc/shadow

Now go back to Falco, and you'll see a message like:

2024-06-21T08:54:23.812791015+0000: Warning Sensitive file opened for reading by non-trusted program (file=/etc/shadow gparent=sudo ggparent=bash gggparent=tmux: evt_type=openat user=root user_uid=0 user_loginuid=1000 process=cat proc_exepath=/usr/bin/cat parent=sudo command=cat /etc/shadow terminal=34826 container_id=host container_name=host)

This is your first Falco event 🦅! If you are curious, this is the rule that describes it.

Create a custom rule

Now it's time to create our own rule and load it into Falco. We can be pretty creative with them, but let's stick with something simple. This time, we want to be alerted when any file is opened for writing in the /etc directory, either on the host or inside containers.

Stop the Falco container with Ctrl-C, copy the following text in a file and call it falco_custom_rules.yaml:

- rule: Write below etc
 desc: An attempt to write to /etc directory
 condition: >
 (evt.type in (open,openat,openat2) and evt.is_open_write=true and fd.typechar='f' and fd.num>=0)
 and fd.name startswith /etc
 output: "File below /etc opened for writing | file=%fd.name pcmdline=%proc.pcmdline gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty"
 priority: WARNING
 tags: [filesystem, mitre_persistence]

Then start Falco again, this time mounting the new rule file:

docker run --rm -it \
 --name falco \
 --privileged \
 -v /sys/kernel/tracing:/sys/kernel/tracing:ro \
 -v /var/run/docker.sock:/host/var/run/docker.sock \
 -v /proc:/host/proc:ro \
 -v /etc:/host/etc:ro \
 -v $(pwd)/falco_custom_rules.yaml:/etc/falco/falco_rules.local.yaml \
 falcosecurity/falco:0.43.0

Finally, open another terminal and write a file in /etc:

sudo touch /etc/test_file_falco_rule

You should see an alert in the Falco terminal, just as before. As you can see, a lot of contextual information is displayed, as it was specified in the output field of the rule. There are many such fields that you can use both in the condition and the output to build your rule.

Docs: Try Falco on Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

First, ensure you can access a test Kubernetes cluster running with Linux nodes, either x86_64 or ARM64. Note that using Docker Desktop on Windows or macOS will not work for this purpose. Also, you will need to have kubectl and helm installed and configured.

Deploy Falco

First, install the helm repository:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

Then install Falco:

helm install --replace falco --namespace falco --create-namespace --set tty=true falcosecurity/falco

And check that the Falco pods are running:

kubectl get pods -n falco

Falco pod(s) might need a few seconds to start. Wait until they are ready:

kubectl wait pods --for=condition=Ready --all -n falco

Falco comes with a pre-installed set of rules that alert you upon suspicious behavior.

Trigger a rule

Let's create a deployment:

kubectl create deployment nginx --image=nginx

And execute a command that would trigger a rule:

kubectl exec -it $(kubectl get pods --selector=app=nginx -o name) -- cat /etc/shadow

Now let's take a look at the Falco logs:

kubectl logs -l app.kubernetes.io/name=falco -n falco -c falco | grep Warning

You will see logs for all the Falco pods deployed on the system. The Falco pod corresponding to the node in which our nginx deployment is running has detected the event, and you'll be able to read a line like:

09:46:05.727801343: Warning Sensitive file opened for reading by non-trusted program (file=/etc/shadow gparent=systemd ggparent=<NA> gggparent=<NA> evt_type=openat user=root user_uid=0 user_loginuid=-1 process=cat proc_exepath=/usr/bin/cat parent=containerd-shim command=cat /etc/shadow terminal=34816 container_id=bf74f1749e23 container_image=docker.io/library/nginx container_image_tag=latest container_name=nginx k8s_ns=default k8s_pod_name=nginx-7854ff8877-h97p4)

This is your first Falco event 🦅! If you are curious, this is the rule that describes it.

Create a custom rule

Create a file and call it falco_custom_rules_cm.yaml with the following content:

customRules:
 custom-rules.yaml: |-
 - rule: Write below etc
 desc: An attempt to write to /etc directory
 condition: >
 (evt.type in (open,openat,openat2) and evt.is_open_write=true and fd.typechar='f' and fd.num>=0)
 and fd.name startswith /etc
 output: "File below /etc opened for writing | file=%fd.name pcmdline=%proc.pcmdline gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty"
 priority: WARNING
 tags: [filesystem, mitre_persistence]

And load it into Falco:

helm upgrade --namespace falco falco falcosecurity/falco --set tty=true -f falco_custom_rules_cm.yaml

Falco pod(s) might need a few seconds to restart. Wait until they are ready:

kubectl wait pods --for=condition=Ready --all -n falco

Then trigger our new rule:

kubectl exec -it $(kubectl get pods --selector=app=nginx -o name) -- touch /etc/test_file_for_falco_rule

And look at the logs:

kubectl logs -l app.kubernetes.io/name=falco -n falco -c falco | grep Warning

You should see a log entry like the one below:

13:14:27.811647863: Warning File below /etc opened for writing (file=/etc/test_file_for_falco_rule pcmdline=containerd-shim -namespace k8s.io -id d5438fedb274ac82963d99987313dae8da512236ace2f70472a772d95090b607 -address /run/containerd/containerd.sock gparent=systemd ggparent=<NA> gggparent=<NA> evt_type=openat user=root user_uid=0 user_loginuid=-1 process=touch proc_exepath=/usr/bin/touch parent=containerd-shim command=touch /etc/test_file_for_falco_rule terminal=34816 container_id=bf74f1749e23 container_image=docker.io/library/nginx container_image_tag=latest container_name=nginx k8s_ns=default k8s_pod_name=nginx-7854ff8877-h97p4)

Deploy Falcosidekick and Falcosidekick UI

In the previous step we displayed the rule output by examining the Falco log for the pod in the cluster that is running on the node. Now we will see how we can forward these alerts to a custom location or display them in a clean GUI. There are many ways to accomplish this but one is by using Falcosidekick which can easily be deployed with the same Helm chart.

Install Falcosidekick and Falcosidekick-UI in your test cluster:

helm upgrade --namespace falco falco falcosecurity/falco -f falco_custom_rules_cm.yaml --set falcosidekick.enabled=true --set falcosidekick.webui.enabled=true

Now check that it is running and its service is set up:

kubectl -n falco get svc

You should see something like this:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
falco-falcosidekick ClusterIP 10.43.212.119 <none> 2801/TCP 61s
falco-falcosidekick-ui ClusterIP 10.43.35.87 <none> 2802/TCP 60s

Display events in the Falcosidekick UI

Forward the UI port, which is 2802:

kubectl -n falco port-forward svc/falco-falcosidekick-ui 2802

And point your browser to http://localhost:2802 . The default username and password are admin / admin.

Now click on "Events" on top of the page and trigger an event again:

kubectl exec -it $(kubectl get pods --selector=app=nginx -o name) -- cat /etc/shadow

You should see an event appearing in the Falcosidekick UI

The Falcosidekick UI can be used to quickly display events but most likely on a production system you will want to forward events to a centralized location. Falcosidekick supports more than 60 integrations. You can find an example below but you can refer to the forwarding documentation to learn more.

Forward events to a Slack webhook

Deploy Falco again, this time disabling the web UI and enabling Slack forwarding. Of course, you can enable both if you wish.

helm upgrade --namespace falco falco falcosecurity/falco \
 --set falcosidekick.enabled=true \
 --set falcosidekick.config.slack.webhookurl=YOUR_WEBHOOK_URL_HERE \
 --set falcosidekick.config.slack.minimumpriority=notice

If Slack is configured correctly, when an event is triggered you should receive a message like the following:

Cleanup

If you wish to remove Falco from your cluster you can simply run:

helm -n falco uninstall falco

Docs: Try Falco on Linux

Mon, 01 Jan 0001 00:00:00 +0000

In this scenario, you will learn how to install Falco on an Ubuntu host, trigger a Falco rule by generating a suspicious event, and then examine the output.

This activity aims to give you a quick example of how Falco works. After you complete it, you should be able to move on to trying Falco on Kubernetes or spend some time reading some additional resources.

Prerequisites

This lab is based on installing Falco on a virtual machine.

The scenario has been tested using VirtualBox and Lima (for MacBooks running Apple Silicon).

While this tutorial may work with Ubuntu running on a cloud provider or another virtualization platform, it has not been tested.

VirtualBox setup

The following steps will set up a VirtualBox virtual machine running Ubuntu 24.04.

Install VirtualBox and Vagrant according to the instructions appropriate for your local system.
Issue the following commands from the command line to create an Ubuntu 24.04 virtual machine.

vagrant init bento/ubuntu-24.04
vagrant up

Log into the newly launched virtual machine and continue to the Install Falco section below (the default password is vagrant).

vagrant ssh

Lima setup for Apple silicon (M1/M2)

This section explains how to create an Ubuntu 24.04 VM on Apple computers running M1 silicon (as opposed to Intel).

If you are unsure what processor your Apple machine is running, you can find out by clicking the Apple icon in the upper left and choosing "About this Mac". The first item listed, Chip, tells you what silicon you're running on.

Install Homebrew according to the project's documentation.
Use Homebrew to install Lima.

brew install lima

Create an Ubuntu 24.04 VM with Lima.

limactl start --name=falco-quickstart template://ubuntu-lts

Shell into the Ubuntu VM, and once you're in the VM, continue to the Install Falco section.

limactl shell falco-quickstart

Install Falco

Regardless of which setup you used above, this section will show you how to install Falco on a host system. You'll begin by updating the package repository. Next, you'll install the dialog package. Then you'll install Falco and ensure it's up and running.

Set up the package repository

Add the Falco repository key.

curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | \
sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg

Add the Falco repository.

sudo bash -c 'cat << EOF > /etc/apt/sources.list.d/falcosecurity.list
deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] https://download.falco.org/packages/deb stable main
EOF'

Read the repository contents.

sudo apt-get update -y

Install dialog

Install dialog, which is used by the Falco installer.

sudo apt-get install -y dialog

Install Falco

Install the latest Falco version.

sudo apt-get install -y falco

When prompted, choose the Modern eBPF option. This will enable the usage of the modern eBPF-based driver.
When prompted, choose Yes. Although we won't use the functionality in this exercise, this option allows Falco to update its rules automatically.

Wait for the Falco installation to complete - this should only take a few minutes.

Verify Falco is running

Make sure the Falco service is running.

sudo systemctl status falco-modern-bpf.service

The output should be similar to the following:

● falco-modern-bpf.service - Falco: Container Native Runtime Security with modern ebpf
 Loaded: loaded (/usr/lib/systemd/system/falco-modern-bpf.service; enabled; preset: enabled)
 Active: active (running) since Wed 2024-09-18 08:40:04 UTC; 11min ago
 Docs: https://falco.org/docs/
 Main PID: 4751 (falco)
 Tasks: 7 (limit: 2275)
 Memory: 24.7M (peak: 37.1M)
 CPU: 3.913s
 CGroup: /system.slice/falco-modern-bpf.service
 └─4751 /usr/bin/falco -o engine.kind=modern_ebpf

Sep 18 08:40:12 vagrant falco[4751]: /etc/falco/falco.yaml
Sep 18 08:40:12 vagrant falco[4751]: System info: Linux version 6.8.0-31-generic (buildd@lcy02-amd64-080) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.2.0-23ubuntu4) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #31-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 20 00:40:06 UTC 2024
Sep 18 08:40:12 vagrant falco[4751]: Loading rules from file /etc/falco/falco_rules.yaml
Sep 18 08:40:12 vagrant falco[4751]: Loading rules from file /etc/falco/falco_rules.local.yaml
Sep 18 08:40:12 vagrant falco[4751]: The chosen syscall buffer dimension is: 8388608 bytes (8 MBs)
Sep 18 08:40:12 vagrant falco[4751]: Starting health webserver with threadiness 2, listening on 0.0.0.0:8765
Sep 18 08:40:12 vagrant falco[4751]: Loaded event sources: syscall
Sep 18 08:40:12 vagrant falco[4751]: Enabled event sources: syscall
Sep 18 08:40:12 vagrant falco[4751]: Opening 'syscall' source with modern BPF probe.
Sep 18 08:40:12 vagrant falco[4751]: One ring buffer every '2' CPUs.

See Falco in action

Generate a suspicious event

There is a Falco rule that is designed to trigger whenever someone accesses a sensitive file (of which, /etc/shadow is one). Run the following command to trigger that rule.

sudo cat /etc/shadow > /dev/null

Examine Falco's output

One of the endpoints that Falco can write output to is syslog. There are multiple ways to examine the system logs, but we have featured two for our exercise: using journalctl and simply using cat on the log file.

Using journalctl

Run the following command to retrieve Falco messages that have been generated with a priority of warning:

sudo journalctl _COMM=falco -p warning

You should see output similar to the following:

...
Sep 18 12:50:52 vagrant falco[4751]: 11:48:24.195279773: Warning Sensitive file opened for
reading by non-trusted program (file=/etc/shadow gparent=sudo ggparent=bash gggparent=sshd
evt_type=openat user=root user_uid=0 user_loginuid=1000 process=cat proc_exepath=/usr/bin/cat
parent=sudo command=cat /etc/shadow terminal=34818 container_id=host container_name=host)
...

Using /var/log/syslog

Log messages describing Falco's activity are logged to syslog. Run the following command to retrieve Falco logs:

sudo grep Sensitive /var/log/syslog

You should see output similar to the following:

...
2024-09-18T12:50:52.164570+00:00 vagrant falco: 11:48:24.195279773: Warning Sensitive file opened for
reading by non-trusted program (file=/etc/shadow gparent=sudo ggparent=bash gggparent=sshd
evt_type=openat user=root user_uid=0 user_loginuid=1000 process=cat proc_exepath=/usr/bin/cat
parent=sudo command=cat /etc/shadow terminal=34818 container_id=host container_name=host)

Cleanup

Remove the Lima virtual machine

If you wish, remove the Lima virtual machine
```
limactl delete falco-quickstart --force
```

Remove the Virtualbox virtual machine

If you wish, remove the Virtualbox virtual machine
```
vagrant destroy
```

Be sure you are in same subdirectory as the Vagrantfile

Docs: Learning Environments

Mon, 01 Jan 0001 00:00:00 +0000

minikube

The easiest way to use Falco on Kubernetes in a local environment is on Minikube.

When running minikube with one of the following drivers virtualbox, qemu, kvm2, it creates a VM that runs the various Kubernetes services and a container framework to run Pods, etc. Generally, it's not possible to build the Falco kernel module directly on the minikube VM, as the VM doesn't include the kernel headers for the running kernel.

To address this, starting with Falco 0.33.0 prebuilt kernel modules and bpf probes for the last 3 minikube major versions, including minor versions, are available at https://download.falco.org/?prefix=driver/. This allows the download fallback step to succeed with a loadable driver. New versions of minikube are automatically discovered by the kernel-crawler and periodically built by test-infra. The supported versions can be found at https://falcosecurity.github.io/kernel-crawler/?target=Minikube&arch=x86_64. Falco currently retains previously-built kernel modules for download and continues to provide limited historical support as well.

You can follow the official Get Started! guide to install.

View minikube Get Started! Guide

Note: Ensure that you have installed kubectl.

Falco with syscall source only

In order to install Falco with the kernel module or the bpf probe:

Create the cluster with Minikube using a VM driver, in this case, Virtualbox:
```
minikube start --driver=virtualbox
```
Check that all pods are running:
```
kubectl get pods --all-namespaces
```

Add the Falco Helm repository and update the local Helm repository cache:

 helm repo add falcosecurity https://falcosecurity.github.io/charts
 helm repo update

Install Falco using Helm:

helm install falco \
 --set driver.kind=modern_ebpf \
 --set tty=true \
 falcosecurity/falco

The output is similar to:

NAME: falco
LAST DEPLOYED: Wed Apr 17 08:19:53 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Falco agents are spinning up on each node in your cluster. After a few
seconds, they are going to start monitoring your containers looking for
security issues.

No further action should be required.

Tip:
You can easily forward Falco events to Slack, Kafka, AWS Lambda and more with falcosidekick.
Full list of outputs: https://github.com/falcosecurity/charts/tree/master/charts/falcosidekick.
You can enable its deployment with `--set falcosidekick.enabled=true` or in your values.yaml.
See: https://github.com/falcosecurity/charts/blob/master/charts/falcosidekick/values.yaml for configuration values.

Check the logs to ensure that Falco is running:

kubectl logs -l app.kubernetes.io/name=falco --all-containers

The output is similar to:

{"level":"INFO","msg":"Resolving dependencies ...","timestamp":"2024-04-17 06:19:49"}
{"level":"INFO","msg":"Installing artifacts","refs":["ghcr.io/falcosecurity/rules/falco-rules:3"],"timestamp":"2024-04-17 06:19:51"}
{"level":"INFO","msg":"Preparing to pull artifact","ref":"ghcr.io/falcosecurity/rules/falco-rules:3","timestamp":"2024-04-17 06:19:51"}
{"level":"INFO","msg":"Pulling layer 1e72f9c4d8fe","timestamp":"2024-04-17 06:19:52"}
{"level":"INFO","msg":"Pulling layer 2e91799fee49","timestamp":"2024-04-17 06:19:52"}
{"level":"INFO","msg":"Pulling layer d4c03e000273","timestamp":"2024-04-17 06:19:52"}
{"digest":"ghcr.io/falcosecurity/rules/falco-rules@sha256:d4c03e000273a0168ee3d9b3dfb2174e667b93c9bfedf399b298ed70f37d623b","level":"INFO","msg":"Verifying signature for artifact","timestamp":"2024-04-17 06:19:52"}
{"level":"INFO","msg":"Signature successfully verified!","timestamp":"2024-04-17 06:19:53"}
{"file":"falco_rules.yaml.tar.gz","level":"INFO","msg":"Extracting and installing artifact","timestamp":"2024-04-17 06:19:53","type":"rulesfile"}
{"digest":"sha256:d4c03e000273a0168ee3d9b3dfb2174e667b93c9bfedf399b298ed70f37d623b","directory":"/rulesfiles","level":"INFO","msg":"Artifact successfully installed","name":"ghcr.io/falcosecurity/rules/falco-rules:3","timestamp":"2024-04-17 06:19:53","type":"rulesfile"}
Wed Apr 17 06:19:54 2024: Falco initialized with configuration file: /etc/falco/falco.yaml
Wed Apr 17 06:19:54 2024: System info: Linux version 5.10.57 (jenkins@ubuntu-iso) (x86_64-minikube-linux-gnu-gcc.br_real (Buildroot 2021.02.12-1-gb75713b-dirty) 9.4.0, GNU ld (GNU Binutils) 2.35.2) #1 SMP Tue Nov 7 06:51:54 UTC 2023
Wed Apr 17 06:19:54 2024: Loading rules from file /etc/falco/falco_rules.yaml
Wed Apr 17 06:19:54 2024: Hostname value has been overridden via environment variable to: minikube
Wed Apr 17 06:19:54 2024: The chosen syscall buffer dimension is: 8388608 bytes (8 MBs)
Wed Apr 17 06:19:54 2024: Starting health webserver with threadiness 4, listening on 0.0.0.0:8765
Wed Apr 17 06:19:54 2024: Loaded event sources: syscall
Wed Apr 17 06:19:54 2024: Enabled event sources: syscall
Wed Apr 17 06:19:54 2024: Opening 'syscall' source with modern BPF probe.
Wed Apr 17 06:19:54 2024: One ring buffer every '2' CPUs.

Falco with multiple sources

Here we run Falco in a minikube cluster with multiple sources: syscall and k8s_audit. The next steps show how to start a minikube cluster with the audit logs enabled and deploy Falco with the kernel module and the k8saudit plugin:

First, we need to create a new folder under the configuration folder of minikube:
```
mkdir -p ~/.minikube/files/etc/ssl/certs
```
We are assuming that the minikube configuration folder lives in your home folder; otherwise, adjust the command according to your environment.

Let's create the needed configuration files to enable the audit logs. We are going to create a new file under ~/.minikube/files/etc/ssl/certs named audit-policy.yaml and copy the required config into it. Copy the following snippet into your terminal shell:

cat << EOF > ~/.minikube/files/etc/ssl/certs/audit-policy.yaml
apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
# Don't generate audit events for all requests in RequestReceived stage.
omitStages:
 - "RequestReceived"
rules:
 # Log pod changes at RequestResponse level
 - level: RequestResponse
 resources:
 - group: ""
 # Resource "pods" doesn't match requests to any subresource of pods,
 # which is consistent with the RBAC policy.
 resources: ["pods", "deployments"]

 - level: RequestResponse
 resources:
 - group: "rbac.authorization.k8s.io"
 # Resource "pods" doesn't match requests to any subresource of pods,
 # which is consistent with the RBAC policy.
 resources: ["clusterroles", "clusterrolebindings"]

 # Log "pods/log", "pods/status" at Metadata level
 - level: Metadata
 resources:
 - group: ""
 resources: ["pods/log", "pods/status"]

 # Don't log requests to a configmap called "controller-leader"
 - level: None
 resources:
 - group: ""
 resources: ["configmaps"]
 resourceNames: ["controller-leader"]

 # Don't log watch requests by the "system:kube-proxy" on endpoints or services
 - level: None
 users: ["system:kube-proxy"]
 verbs: ["watch"]
 resources:
 - group: "" # core API group
 resources: ["endpoints", "services"]

 # Don't log authenticated requests to certain non-resource URL paths.
 - level: None
 userGroups: ["system:authenticated"]
 nonResourceURLs:
 - "/api*" # Wildcard matching.
 - "/version"

 # Log the request body of configmap changes in kube-system.
 - level: Request
 resources:
 - group: "" # core API group
 resources: ["configmaps"]
 # This rule only applies to resources in the "kube-system" namespace.
 # The empty string "" can be used to select non-namespaced resources.
 namespaces: ["kube-system"]

 # Log configmap changes in all other namespaces at the RequestResponse level.
 - level: RequestResponse
 resources:
 - group: "" # core API group
 resources: ["configmaps"]

 # Log secret changes in all other namespaces at the Metadata level.
 - level: Metadata
 resources:
 - group: "" # core API group
 resources: ["secrets"]

 # Log all other resources in core and extensions at the Request level.
 - level: Request
 resources:
 - group: "" # core API group
 - group: "extensions" # Version of group should NOT be included.

 # A catch-all rule to log all other requests at the Metadata level.
 - level: Metadata
 # Long-running requests like watches that fall under this rule will not
 # generate an audit event in RequestReceived.
 omitStages:
 - "RequestReceived"
 EOF

Create the file webhook-config.yaml and save the required configuration needed by the k8s api-server to send the audit logs to Falco:

cat << EOF > ~/.minikube/files/etc/ssl/certs/webhook-config.yaml
apiVersion: v1
kind: Config
clusters:
- name: falco
 cluster:
 # certificate-authority: /path/to/ca.crt # for https
 server: http://localhost:30007/k8s-audit
contexts:
- context:
 cluster: falco
 user: ""
 name: default-context
current-context: default-context
preferences: {}
users: []
EOF

Once the configuration files are in place we are ready to start the minikube cluster:

minikube start \
 --extra-config=apiserver.audit-policy-file=/etc/ssl/certs/audit-policy.yaml \
 --extra-config=apiserver.audit-log-path=- \
 --extra-config=apiserver.audit-webhook-config-file=/etc/ssl/certs/webhook-config.yaml \
 --extra-config=apiserver.audit-webhook-batch-max-size=10 \
 --extra-config=apiserver.audit-webhook-batch-max-wait=5s \
 --cpus=4 \
 --driver=virtualbox

 We need at least 4 CPUs for the VM to deploy Falco with multiple sources!

Add the Falco Helm repository and update the local Helm repository cache:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

Install Falco using the pre-set values file:

helm install falco \
 --set driver.kind=modern_ebpf \
 --set tty=true \
 --values=https://raw.githubusercontent.com/falcosecurity/charts/master/charts/falco/values-syscall-k8saudit.yaml \
 falcosecurity/falco

Check that the Falco pod is up and running:

kubectl get pods -l app.kubernetes.io/name=falco

Execute the following command and keep the terminal open:
```
kubectl logs -l app.kubernetes.io/name=falco -f
```
The command will follow the log stream of the Falco pod by printing the logs as soon as Falco emits them. And make sure that the following lines are present:
```
Mon Oct 24 15:24:06 2022: Opening capture with plugin 'k8saudit'
Mon Oct 24 15:24:06 2022: Opening 'syscall' source with modern BPF probe
```
It means that Falco is running with the configured sources.

Trigger some rules to check that Falco works as expected. Open a new terminal and make sure that your kubeconfig points to the minikube cluster. Then run:

Trigger a k8saudit rule:

kubectl create cm myconfigmap --from-literal=username=admin --from-literal=password=123456

In the terminal that we opened in step 8 we should see a log line like this:

15:30:07.927586000: Warning K8s configmap with private credential (user=minikube-user verb=create resource=configmaps configmap=myconfigmap config={"password":"123456","username":"admin"})

Trigger a Falco rule:

kubectl exec $(kubectl get pods -l app.kubernetes.io/name=falco -o name) -- cat /etc/shadow

Check that a log similar to this one has been printed:

15:32:04.318689836: Warning Sensitive file opened for reading by non-trusted program (file=/etc/shadow gparent=systemd ggparent=<NA> gggparent=<NA> evt_type=openat user=root user_uid=0 user_loginuid=-1 process=cat proc_exepath=/usr/bin/cat parent=containerd-shim command=cat /etc/shadow terminal=0 container_id=38e44b926166 container_image=falcosecurity/falco container_image_tag=0.40.0-debian container_name=k8s_falco_falco-bggd7_default_7bb0145f-dca5-452d-a670-01e23d839e5a_1 k8s_ns=<NA> k8s_pod_name=<NA>)

kind

kind lets you run Kubernetes on your local computer. This tool requires that you have Docker installed and configured. Currently not working directly on Mac with Linuxkit, but these directions work on Linux guest OS running kind.

The kind Quick Start page shows you what you need to do to get up and running with kind.

View kind Quick Start Guide

To run Falco on a kind cluster is as follows:

Create a configuration file. For example: kind-config.yaml

Add the following to the file:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
 extraMounts:
 # allow Falco to use devices provided by the kernel module
 - hostPath: /dev
 containerPath: /dev
 # allow Falco to use the Docker unix socket
 - hostPath: /var/run/docker.sock
 containerPath: /var/run/docker.sock

Create the cluster by specifying the configuration file:
```
kind create cluster --config=./kind-config.yaml
```
Deploy Falco with Helm.

MicroK8s

MicroK8s is the smallest, fastest multi-node Kubernetes. Single-package fully conformant lightweight Kubernetes that works on Linux, Windows, and Mac. Perfect for: Developer workstations, IoT, Edge, CI/CD.

You can follow the official Getting Started guide to install.

Once the MicroK8s cluster is up and running, you can deploy Falco with Helm.

Docs: Additional Resources

Mon, 01 Jan 0001 00:00:00 +0000

Learn more about Falco

If you'd like to dive deeper into the various components that make up Falco, check out the following resources:

Understand Falco's event sources
Learn more about Falco Rules
Review Falco Alerts
Discover Falco Plugins
Read the Falco Glossary