Blog Icon

Blog Post

Runtime Security for Kubernetes with Falco

The power of Kubernetes is how easy it is to quickly deploy and scale containerized applications. Developers can quickly package their application in a container, and then deploy it with just a few lines of YAML. However, this model requires for you to rethink how you handle container runtime security. How do you know what is running in that prepackaged container? How do you monitor the security of this container and watch for malicious activity?

Sysdig Falco is an open source, container security monitor designed to detect anomalous activity in your containers. Sysdig Falco taps into your host’s (or Node’s in the case Kubernetes) system calls to generate an event stream of all system activity. Falco’s rules engine then allows you to create rules based on this event stream, allowing you to alert on system events that seem abnormal. Since containers should have a very limited scope in what they run, you can easily create rules to alert on abnormal behavior inside a container.

Falco provides rules for common antipatterns such as:

  • Spawning a shell in a container

  • Config files being written in /etc

  • Binaries changing

  • Package management running

Running Falco as a Daemon Set

Note: You can find the code for the below example in the Falco GitHub repository.

Falco can be ran as a Daemon Set on Kubernetes to monitor any containers running. You can find examples of how to run a Falco Daemon Set in the project’s GitHub repo. The first thing you’ll need to do is create the service account and grant the account the appropriate permissions. The Falco pods will use this service account to authenticate with the Kubernetes API. With this integration to the Kubernetes API, Falco allows you to include Kubernetes specific data (Pod name, Node name, etc) in any alerts Falco generates.

Creating a Service Account for Falco Once the service account is created, we can create a ConfigMap to store Falco’s rules and configuration. While the Falco Docker image could be ran without the ConfigMap, you will most likely want to modify the configuration, and the ConfigMap provides a convenient place to store your custom configuration. For example, you can modify the falco.yaml config to send a message to a Slack webhook.

  enabled: true
  keep_alive: false
  program: "jq '{text: .output}' | curl -d @- -X POST"

Creating a ConfigMap for Falco

Now that we laid down the accounts and config Falco needs, we can create the Daemon Set. The Daemon Set will run a Pod on every Kubernetes Node in order to create an event stream from the system calls of that host. Each Pod will also pull down the configuration we created with the ConfigMap.

Creating a Daemon Set for Falco

Now that our Daemon Set is deployed, any behavior seen as abnormal will notify our Slack channel. For example, if we do a kubectl exec to a Pod and open a bash shell, Falco will send a message to Slack.

Falco Events in Slack

You can also use the Falco Event Generator to test your Falco setup. You can read more about the event generator in Falco’s documentation. The event generator is available as a Docker container, and we provide a Kubernetes Deployment to deploy the event generator to a Kubernetes Cluster.

Sysdig Falco provides an easy way to alert when a container behaves outside what is considered normal. You can easily extend the Falco rule set to take into account scenarios specific to your environment. Refer to the Falco documentation to learn more about writing your own rules. There’s also example rules for specific applications such as MongoDB, Elastic Search, and Kafka.

Sysdig Secure

If you like the functionality of Sysdig Falco, but want more integrations, user activity auditing, the ability to kill or pause containers based on rules, and the ability to capture the state of a container when a rule fails check out Sysdig Secure. You can request a customized demo, or kick off a trial.

Share This

Stay up to date

Sign up to receive our newest.