Introduction

This is the second post in a series related to the Certified Kubernetes Security Specialist (CKS) certification I achieved recently. In the previous part we discussed my preparation, the exam attempts themselves, the hurdles, lessons learned and key takeaways. Now we will take a deeper dive into the technical content of the exam.

This part will cover what to expect and how to prepare for the Falco related questions on the CKS exam. To be clear: I will not provide you with answers to any questions, rather we will look at the methods of solving these questions. There are some neat tricks I hope to teach you, tips that I could have used when I was preparing myself for the exam.

Runtime Security with Falco

One of the major tools covered under the Runtime Security section is Falco. It’s a threat detection tool for hosts, containers, kubernetes and cloud environments. Originally created by Sysdig, it is now a graduated project under the Cloud Native Computing Foundation (CNCF). It is designed to detect abnormal behaviour and security threats in real-time by plugging into the kernel via eBPF. We will not dive into eBPF here, but it’s an awesome technology that allows us to extend the kernel’s capabilities without changing it’s source code. Falco uses it to extract metadata information about processes and then validates these kernel events against specified rules in the configuration. Alerts can be generated and sent to external systems when a rule is violated. Rules in the configuration can be customised extensively to fit your needs. You can do so much!

Some of the most useful detection patterns are:

  • Privilege escalation
  • Accessing important files and directories
  • Ownership changes
  • Unexpected connections
  • Executing shells or SSH binaries

By default, a Falco configuration file will be present on your host(s) at /etc/falco/falco.yaml . This file has the following section configured. This is used to load different rules into the configuration. As you can see there are three entries. This can be adjusted to your needs.

rules_files:
  - /etc/falco/falco_rules.yaml
  - /etc/falco/falco_rules.local.yaml
  - /etc/falco/rules.d
  • falco_rules.yaml contains the default set of rules.
  • falco_rules.local.yaml :can be used to add custom rules.
  • rules.d is a directory that can contain custom rules if you want to take a more organised approach and organize them in multiple files.

During the exam there will be a few deployments running, some of them having a process that is doing we don’t want to allow according to the scenario in the question. You need to scale down the deployments that violate the specified scenario. In theory you don’t even have to touch Falco, if you are a psychic who can guess which deployment(s) need to be scaled down. In practice, creating a custom Falco rule is the quickest way forward. The following is a template with all mandatory fields, which you can use to quickly create a new rule.

- rule: my_custom_rule # Name of the rule
  desc: notice my custom event # Description of the rule
  # Condition of the rule. This will determine when the alert is triggered.
  condition: >
    ... 
  # This is the text that will be displayed, logged or sent in an alert
  # once the condition above is triggered.
  output: >
    ...
  # The priority level marks the importance and is used to filter output
  #   on or to route it to different destinations.
  priority: WARNING

Place this template in a new yaml file my_rule.yaml and fill in the condition and output according to the question. You should be familiar with at least the basics of conditions. The documentation is very clear and clearly explains each field and how to use them. If you want to access the list of fields quickly on the exam without going to the documentation, use the falco --list command. This will achieve the same thing, and pipe to grep for filtering the output. Much more efficient!

Conditions at it’s base can be quite simple. Definitely take a look at the default rules. A simple example is checking if a new bash process is spawned with:

condition: >
  container.id != host and 
  proc.name = bash

In the real world this is not necessarily the greatest of conditions and can use quite some optimisation with evt.dir and evt.type for example. For the exam this is not needed at all, just get it working! To speed up your condition writing skills make sure to know the most important fields like the ones related to; files, processes, etc.

Next, define your output. This is quite simple as you just need to log which container is violating the rule. Use %container.id to identify which one. With the id, use your container runtime commands like docker inspect {id} to look at the configuration. This will guide you to the right deployment to scale down. Look for similarities like e.g. the name.

Once you have configured the rule correctly including the condition and mapping the output it’s time to start using it. I’ve seen many CKS courses and training material use the existing rule files. The existing rules may or may not create confusing output. You might also notice that the output configuration on the exam is different and that you need to adjust it before seeing any of the logs for the rule you created. Don’t do any of this during your exam, stop wasting valuable time. This was something that stunned me the first time around. It took a lot of time to get some simple output.

The fastest way of achieving the same goal is using a simple Falco command like the one below specifying the rule we created in our yaml file. This will always print the output in our terminal, and just for our rule.

falco -r my_rule.yaml

Taking advantage of features like this shows real mastery of the tools you are using. In the end, it’s this type of efficiency that will get you through the exam or not.

That was it for part 2. Thank you for reading this blog and I hope it helps you gain some insights into Falco as well as manage your expectations for the exam . In the next part we continue with other technical topics that are part of the CKS exam. Be on the lookout for another post covering how to implement Falco on your clusters.