Cloud Security · Topic 5 of 6
Application and Workload Security Concepts Including eBPF
Learn application and workload security for VMs, containers and serverless, including runtime protection, microsegmentation and eBPF kernel visibility.
- 4 min
- Containers share the host kernel, so isolation is weaker than for a virtual machine.
- Workload security uses hardening, least privilege, microsegmentation and runtime protection.
- eBPF runs sandboxed programs inside the Linux kernel.
What it is
Workload security protects the thing that runs your code, whether that is a virtual machine, a container or a function.
Application security protects the code and its interfaces. Workload security protects the runtime around it. eBPF is a Linux kernel technology that lets security tools watch and control workloads efficiently, without changing the application.
How it works
Cover the workload types and their risks first, then see why eBPF is useful.
Workload types and risks
| Workload | Characteristics | Typical risks |
|---|---|---|
| Virtual machine | Full operating system, long lived | Unpatched software, open ports, lateral movement |
| Container | Shares the host kernel, short lived | Vulnerable images, excess privilege, escape to host |
| Serverless function | Code only, runs on demand | Over permissive roles, injection, vulnerable libraries |
Containers share the host kernel, so isolation is weaker than a virtual machine. A flaw in one container, or too many privileges, can affect the host and the other containers on it.
Application security concepts
Application security covers the code and the way it is reached.
- Secure coding and testing: find flaws before release.
- WAF and API protection: filter hostile requests at runtime.
- Identity and secrets: short lived credentials, and no secrets in code.
- Dependency control: know which libraries you use, and patch them.
Workload security controls
Several controls apply to all workload types.
- Hardening and patching: remove what you do not need and update the rest.
- Least privilege: run with the minimum permissions and drop extra capabilities.
- Microsegmentation: allow only the flows that the application needs.
- Runtime protection: watch processes, files and network calls for abnormal behaviour.
- Image and vulnerability scanning: check images and hosts for known flaws.
- Logging: send workload events to a central place.
What eBPF is
eBPF (extended Berkeley Packet Filter) lets small programs run safely inside the Linux kernel. Before a program loads, a verifier checks it, to confirm that it cannot crash the kernel or loop forever. This gives kernel level access without writing a kernel module or recompiling the kernel.
An eBPF program attaches to hooks, such as system calls, network events and function calls. It can count, filter, record or, in some cases, block activity at those points. The data goes to user space tools that apply the logic.
Why eBPF suits security
The kernel sees everything that the workloads on a host do. eBPF uses that view with low overhead, and with no change to the application or the container image.
| Benefit | Explanation |
|---|---|
| Deep visibility | Sees process starts, file access, system calls and network flows |
| Low overhead | Runs in the kernel, so there is little extra copying |
| No app changes | Works without modifying code or adding a sidecar |
| Real time enforcement | Can block a bad action as it happens |
| Container awareness | Can tie events to a pod, namespace or container |
Typical eBPF uses
In networking, eBPF can enforce policy, balance load and provide observability in Kubernetes. In security, it can detect a shell that starts inside a container, a sensitive file being read, or an unexpected outbound connection. Open source projects such as Cilium and Tetragon use eBPF for Kubernetes networking and runtime security.
Limits
eBPF needs a suitable Linux kernel, so it is mainly for Linux hosts and container nodes. The tool you use decides what it can see and enforce. It complements other controls, and does not replace image scanning, patching or identity controls.
What to remember for the exam
Six facts cover most questions on this topic.
- Containers share the host kernel, so isolation is weaker than for a virtual machine.
- Workload security uses hardening, least privilege, microsegmentation and runtime protection.
- eBPF runs sandboxed programs inside the Linux kernel.
- A verifier checks an eBPF program before it loads.
- eBPF gives deep visibility and enforcement with low overhead and no application change.
- eBPF is mainly a Linux technology, and it complements other controls.
If a question asks for kernel level visibility into containers without changing the application, think eBPF.
Common mistakes
These four mistakes appear often.
Thinking eBPF needs a kernel module. It does not, because it loads verified programs into the running kernel.
Treating containers like virtual machines. They share the kernel, so a container escape is a real concern.
Running containers as a privileged user. Extra privileges make an escape easier.
Expecting eBPF to patch software. It watches and controls behaviour, but it does not fix the vulnerable code.
Runtime tools see only the hosts where they are deployed. An unmonitored node or workload is a blind spot.
Check yourself
Work through these three questions.
Why is a container less isolated than a virtual machine?
Containers share the host kernel, so a flaw or excess privilege can affect the host and other containers.
What does the eBPF verifier do?
It checks a program before it loads, to make sure that it cannot crash the kernel or run forever.
Why is eBPF useful for workload security?
It gives deep kernel level visibility and enforcement with low overhead, and without changing the application.
Topic 5 of 6 in Cloud Security
Test yourself on Cloud Security
The full Cisco CCNP 350-701 SCOR question bank has 822 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Cisco. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.