Microservice Vulnerabilities: Secure Deployments and Runtime

When you build software today, you rarely create one giant program. Instead, you break it into many small, independent services that talk to each other over a network. Each of these small services is called a microservice. Think of them like separate workers in a factory: one worker only puts wheels on cars, another only paints the car body, another only tests the engine. If one worker gets sick (or compromised by a hacker), the others can keep working. But this design creates a new problem: how do you stop a compromised microservice from damaging others?

That is where runtime security tools come in. Runtime means the period when the software is actually running and doing its job — not when it is being written or installed. Vulnerabilities are weaknesses that an attacker could exploit. So 'microservice vulnerabilities' are the gaps that let an attacker break a microservice while it is running.

The CKS exam focuses on three specific tools that secure microservices at runtime: Falco, AppArmor, and Seccomp. Let us break down each one.

Falco is a runtime security monitoring tool created by Sysdig. It acts like a security camera that watches every action happening inside your containers (containers are lightweight, portable environments that run each microservice). Falco looks for unexpected behaviour — for example, a microservice that suddenly starts writing to the system's password file, or a process that tries to open a network connection to an unknown server. When Falco detects something suspicious, it can send an alert to your security team or even trigger an automatic response, like stopping the container. Falco uses 'rules' — simple text files that define what is normal and what is suspicious. You can write your own custom rules to match your specific application.

AppArmor is a Linux kernel security module that lets you restrict what a program can do. Think of it as a strict rule book for each application. When you create an AppArmor profile for a microservice, you define exactly which files it can read, which directories it can write to, which network connections it can make, and which other programs it can run. If the microservice tries to do anything not in the profile, the kernel blocks it immediately. For example, if your microservice is a simple web server and its AppArmor profile says it can only read files in the /var/www directory, and then an attacker tricks it into trying to read /etc/shadow (where passwords are stored), AppArmor stops that action. AppArmor profiles are enforced at the kernel level, so even if the microservice itself is hacked, the hacker cannot bypass AppArmor unless they also break out of the kernel — which is extremely difficult.

Seccomp (short for secure computing mode) is another Linux kernel security feature. It filters the 'system calls' that a program can make. System calls are the way a program asks the operating system to do something — like open a file, send data over a network, or create a new process. Every program needs some system calls, but many programs do not need dangerous ones like 'ptrace' (which can be used to debug or hijack other programs) or 'mount' (which lets you attach filesystems). With Seccomp, you create a profile that lists exactly which system calls are allowed (whitelist) or which are blocked (blacklist). If your microservice tries to make a blocked system call, the kernel kills the process or prevents the call. This is especially important because many container exploits rely on calling unusual system calls to break out of the container.

Why do you need all three? Because each tool covers a different layer. Falco watches behaviour at a high level (processes, network, files) and alerts you. AppArmor restricts access to files and capabilities at the kernel level. Seccomp controls the lowest level — the system calls themselves. Using them together gives you 'defence in depth', meaning if one layer fails, the others still protect you.

In the old days, before microservices, you might have run one big application on a physical server. You could trust that application implicitly because it was the only thing running. But today, with dozens or hundreds of microservices running on the same machine in containers, you cannot trust any single one. That is why runtime security tools are essential. They enforce the principle of least privilege, which means giving each microservice only the permissions it absolutely needs to do its job — nothing more.

When you deploy a microservice in Kubernetes (the system that manages containers), you can attach AppArmor and Seccomp profiles to your pods (a pod is the smallest unit in Kubernetes, usually containing one container). You can also install Falco as a DaemonSet (a special Kubernetes object that runs on every node in the cluster) to monitor all activity. The CKS exam expects you to know how to configure these for a deployment.

Imagine you are the security engineer at a mid-sized online retail company. Your team has built a microservices-based application that handles customer orders, payments, inventory, and shipping. Each microservice runs in its own container on a Kubernetes cluster. One day, a developer accidentally exposes a debug endpoint in the payment microservice, and an attacker discovers it. The attacker sends a crafted request that lets them execute arbitrary commands inside the payment container.

Here is what happens step by step when you have runtime security in place:

In a real organisation, you would also use tools like: