Keeping integrations apart

An integration is Java code that its authors wrote, so the boundaries between integrations are where the operating system and the hub’s credentials enforce them. At a site the boundary is the agent: each agent reaches only the projects and environments an administrator allowed it. At the hub every build of an integration runs isolated, with only the files and connections it needs.

The agent is the boundary#

Within one agent, integrations aren’t isolated from each other. Every flow of an agent runs as the agent’s user, so code in one integration could read the files of its neighbours on that agent. Integrations that must not see each other’s data, such as two suppliers’ code, therefore run on agents with different allowed projects:

$ weikio agent enrol supplier-a-01 --host linux-compose --capabilities environment=production --projects supplier-a --out ./supplier-a-01
$ weikio agent enrol supplier-b-01 --host linux-compose --capabilities environment=production --projects supplier-b --out ./supplier-b-01

That separation applies at every step, because everything an agent reaches from the site is named after a project. The store its code comes from and the entity-store buckets its flows read and write carry the project’s ID in their names, and the agent’s credential for its link to the hub lists only its own projects and environments. Nothing that runs at the site can widen that, and only an administrator changes it.

One agent can serve several environments. A site that wants two environments kept apart runs two agents, each with its own link to the hub, and the hub enforces the separation.

What a site’s credential reaches#

The site’s link carries exactly what its agent needs: its own control requests, the event channels of its allowed projects and environments, and read access to the code and entity stores of those projects. Agents only ever read code from the hub, and nothing at a site can write into a project’s code store.

Each deployment’s JVM gets a telemetry credential of its own when it starts, made for that deployment, and the hub writes into every stored line, span and figure the project, environment, integration and agent that credential proves. One integration can’t file its log lines or numbers under another project. When the deployment is deleted, or its agent revoked, its credential stops working.

When an administrator changes an agent’s environments or projects, the hub issues a new credential, the agent fetches it, and the platform withdraws the one it replaced. A revoked agent’s link goes down as soon as the revocation reaches the hub’s message server, which refuses the site from then on.

Builds at the hub#

The hub builds every version of an integration once, from its authors’ code. On Linux 6.7 or later with Landlock enabled, Ubuntu 24.04 among them, each build step:

• reads only the JDK, the Camel launchers, the system folders, the Maven settings, the libraries the platform downloaded and the folders it may write
• writes only its own build folder and its project’s own Maven folder, and can’t change the Maven settings it reads
• makes TCP connections only to the ports of the Maven repositories, mirror and proxy the hub is set up with
• can’t read the installation’s keys, the master key or the other secret files the backend has, can’t make a symbolic link, and runs with a fixed environment and with Java’s attach mechanism off

The backend reads build output without following a symbolic link. A build step can read the repository credentials in the Maven settings, so give the hub a repository account that can only read.

The builder section of doctor gives what the host provides:

$ docker compose run --rm infra weikio-backend doctor

On an older kernel builds still run with less isolation, and doctor warns. Below Linux 6.7 a step’s TCP connections aren’t limited, and below Linux 5.13, or with Landlock off at boot, its reads and writes aren’t either. On every kernel, a step’s UDP traffic, unix sockets and signals are outside these rules, and the TCP rule limits the repositories’ ports, not their hosts.

Each project builds on its own#

Each project’s builds keep their own Maven folder and build cache, so no build uses libraries or compiled classes that another project’s build wrote. A project’s first build on a Camel version downloads what the platform’s own folder lacks into the project’s folder, so every project uses some disk of its own. Deleting a project deletes its Maven folder and build cache once its running builds end, so a project created later under the same name starts clean.