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 its 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.

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, which is used to load different rules into the configuration:

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 organise them in multiple files.

Writing a Custom Rule

During the exam there will be a few deployments running, some of them having a process that is doing something 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 deployments 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:

- 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 explains each field thoroughly. If you want to access the list of fields quickly on the exam without going to the documentation, use the falco --list command and pipe to grep for filtering. Much more efficient!

Conditions at their base can be quite simple. A straightforward example is checking if a new bash process is spawned:

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

In the real world this can use quite some optimisation with evt.dir and evt.type for example. For the exam this is not needed — just get it working! Make sure to know the most important fields related to files, processes, etc.

Next, define your output. Log which container is violating the rule using %container.id to identify it. 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.

The Fastest Way to Run Your Rule

I’ve seen many CKS courses use the existing rule files during practice. Don’t do this on the exam — the existing rules may create confusing output, and adjusting the output configuration wastes valuable time. This stunned me on my first attempt.

The fastest way forward is a simple Falco command that runs only your rule file:

falco -r my_rule.yaml

This will always print the output to your terminal, and only for your rule. Taking advantage of features like this shows real mastery of the tools you’re 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. In the next part we continue with other technical topics covered in the CKS exam — specifically Cilium Network Policies.