Who may do what

Two ways in, one user behind them

A person signs in with a name and a password and carries on with a session. A script uses an API key, which belongs to a user and does not expire — that is what a build pipeline wants and what a person does not need.

At the very first start one root key comes into being and is written to a file only root can read. It is the way back if the password login ever stops working, and it exists precisely so that nobody has to leave a second door open for that case.

Permissions per action, not per person

Rights are named after an area and an action — view, create, change, power, console, snapshot, export, delete — and hang directly off the user. There is one catalogue for all of it, and it serves three things at once: the check in the program, the editor in the interface, and the ready-made sets. A permission missing from that catalogue exists nowhere.

Some rights are separated on purpose rather than lumped in with a neighbour. Exporting is not part of cloning, because whoever may export and download holds the whole disk of a guest. Applying an update is not part of seeing the host, because it replaces the program code that runs as root. Searching the memory of a halted guest is not part of running the emergency brake, because that image holds everything that was in the guest at the moment it stopped.

Ready-made sets — view only, VM operation, VM administration, container administration — set the ticks, and every tick can still be changed one by one afterwards.

Encrypted from the first start

The interface and the API run over TLS out of the box; a certificate is produced at the first start. Where a domain points at the host, a publicly trusted certificate can be obtained and adopted.

The server reads its certificate files when it starts, so a change needs a restart. Whether one is outstanding is worked out by comparing the file with the running process — which means nobody has to remember it.

An update that cannot be swapped on the way

An update replaces program code that runs as root. Whoever can decide what arrives owns every host it arrives on, and that is true on both paths: online, somebody could take over the connection; offline, the file travels by USB stick or mail and nobody can tell by looking at it whether it was changed.

So every package carries a signature, and without a valid one nothing is unpacked. The public key sits in the program; the private one belongs solely on the machine where packages are built. Signed is the payload itself and not the description of it — otherwise a genuine signature could be combined with somebody else's contents.

The same shape carries the licensing: only the public key is in Phillux, so nobody can issue a licence out of an installation — not even whoever holds the source and the database.