eBPF: trust put to the test of the cloud

At Alien6, we have been experimenting with eBPF for some time to make it one of the foundations of our application architecture, with three goals: containing incidents, easing audits and preserving service continuity.

Imagine a building where badges are perfectly managed, but where the interior doors remain open. The register states who may access each room, but in practice, anyone who has entered the building can move around far more freely.

An application architecture can exhibit such gaps when its internal access is too permissive. A compromised reporting application can then become a starting point towards more sensitive services.

For our clients, this risk goes beyond the failure of one application. It concerns the propagation of the incident, the interruption of business and the time needed to understand what was exposed.

What eBPF makes possible, concretely

eBPF is a technology built into the Linux kernel, the core of the operating system that manages processes and communications, among other things. It makes it possible to run small programs there to observe activity and enforce certain security controls.

An eBPF program can, for example, intervene when an application attempts a connection and refuse it if the access rules forbid it, within the perimeter it controls.

In our building metaphor, eBPF makes it possible to install turnstiles at certain passage points. The register of authorisations thus finds a concrete extension in the system.

The turnstile must keep knowing who is supposed to pass, even when the occupants change. In the cloud, these changes are part of normal operation. This is where an important part of our experimentation begins.

Perpetual motion

An application generally keeps its role while the elements executing it change. Its instances are replaced, their number varies and they move between machines. One dependency is added, another disappears.

Security must follow this motion. An authorisation granted to a service must keep applying to the right service after a restart. It must not be handed over to another component that would take its place. It must also be able to disappear when the need that justified it no longer exists.

This continuity looks natural on an architecture diagram. It becomes harder to maintain when several applications evolve simultaneously.

Our experiments around eBPF focus in particular on this correspondence between the services we want to authorise and the components that actually communicate.

Getting closer to the kernel also raises responsibility

eBPF makes it possible to bring certain controls closer to the communications they must govern. Intervening at this level, however, requires weighing the consequences of a mistake.

A rule that is too permissive can leave an unwanted access open. A rule that is too restrictive can interrupt a process, block a transaction or make an application unavailable.

For our clients, protection must remain compatible with the operation of the business. For operations teams, it must also remain understandable. A refusal must be explainable. A degradation must be distinguishable from an application or network problem. Without this visibility, a security mechanism can lengthen diagnosis and complicate service recovery.

We therefore work as much on the understandability of the controls as on their ability to block a communication.

Transitions reveal the difficulties

The most instructive situations often appear during a change. An authorisation is withdrawn while a connection is still active. A component restarts while new rules are being propagated. One service is declared ready, while another does not yet have the information needed to recognise it.

Our integration trials have already revealed this gap between the state announced by a component and the state actually available elsewhere in the system. The register is up to date; the turnstile has not yet received the new instruction.

The difficulty increases when part of the control system becomes unavailable. Applications must keep working as much as possible, without this continuity silently prolonging rights that should no longer exist.

These situations place security and availability in the same equation. They occupy an important part of our R&D, because their consequences translate directly into how applications behave.

Components that become the foundations of our projects

The identity of services, control over their communications and the understanding of their dependencies concern every one of our projects. As architectures grow, these requirements must retain overall coherence.

The components stemming from our R&D are progressively becoming this shared base. The eBPF experimentation naturally finds its place there, because it forces us to confront the rules we define with the exchanges that actually occur.

This work influences the design of our new projects: the access planned from the start, the dependencies accepted and the guarantees we want to be able to verify.

This is how we build the Zero Trust foundations of our projects, with security requirements tied to operational constraints and to our clients' risks.