Firewall as a policy

In Flui the firewall is derived from what the cluster needs. It is installed when the cluster is created, applied to every node automatically and kept in sync as the cluster’s shape changes. Flui owns the firewall and its rules. You state which addresses may come in for operator access, and Flui derives the rest.

The default policy

Every Flui cluster comes up with the same baseline policy:

Port	Source	Reason
22/tcp (SSH)	a user-controlled allow-list where the provider has an edge firewall Flui drives (auto-detected operator IP, or values you pass); elsewhere open, but only certificates of the installation get in	Operator access for bootstrap and diagnostics
80/tcp, 443/tcp (HTTP, HTTPS)	open to the world	Public ingress for the cluster’s applications and platform components
Outbound	allow-all	Apps need to reach external services, registries, certificate authorities

Everything else stays closed at the public perimeter. The one addition is the Flui network’s own port on the control cluster, open only to the addresses of the clusters that belong to the installation. The cluster runtime and the platform components talk to each other on the private network without needing a firewall opening (see VNets and subnets, abstracted).

The cluster’s own control port is an example. It is not in the default rules, because the control plane reaches a workload cluster over the private VNet using the master’s private address. If you write a rule for that port, Flui makes sure the subnet’s own range is among its sources before applying it. It adds the private range instead of replacing what you wrote, so your exception survives and the cluster stays reachable from inside its own network.

With the default, the cluster is usable as soon as it comes up, with the SSH allow-list bound to your workstation and everything else closed. The change you will make most often is updating that allow-list, usually when your IP changes or when more operators need access. Use flui env update-firewall, which takes --ip with an IP or a comma-separated list of CIDRs, or no flag at all, in which case it detects your current public address. --add and --remove edit the list instead of replacing it, --list prints it and changes nothing, and the command refuses a change that would leave the list empty. It touches only the SSH rule and leaves every other rule as it is. It updates the rules Flui keeps, so a later reconcile does not undo it. When the Flui API does not answer, it writes to the provider directly, so it still works when your current address is the one locked out; run it again once the API answers.

When the default policy is not what you need, the dashboard has a full firewall editor: you can add, change or remove rules from the cluster’s Firewall tab through View & Manage Rules, and the API accepts the same operations.

The rules you cannot remove

Because you can edit the rules, the platform holds a few of them in place. A misconfigured firewall (a missing SSH rule, a stray block on the certificate renewal path) is one of the most common ways to lock an operator out of a cluster, or a cluster out of its own certificates. So Flui enforces three invariants on every write, at cluster creation and on every later update:

• Ports 80 and 443 always stay open inbound. If a submitted rule set leaves one out, Flui puts it back, open to the world, and says so in the log. You can restrict the source of those ports, but you cannot remove the port.
• A workload cluster always admits the control plane on SSH. Flui manages that cluster over SSH, so the control plane’s own addresses are added to the SSH allow-list rather than replacing it. On a provider that filters at its own edge, a cluster created from the CLI admits only the control cluster on SSH; one created from the dashboard also admits the address you created it from. Use flui ssh and the control cluster’s path rather than connecting directly.
• A rule open to the whole IPv4 internet is opened to IPv6 too. Nodes have addresses on both, and a firewall drops what its rules do not match instead of refusing it. A lone IPv4 wildcard would turn every IPv6 host into a black hole that looks like a slow connection instead of an error. Lists that name specific ranges are left alone: someone chose to narrow that source, and widening it would undo their choice.

Ports that answer only over the tunnel

A third category sits between “open” and “closed”, and it exists because of the network described in The network Flui builds.

Some ports must be reachable by the installation and by nobody else: a cluster’s control-plane port, and the two that receive logs and metrics. On a single-provider installation the private network handles that, because the ports are scoped to it. Across providers there is no such network to scope to, and the addresses involved can change.

So the rule names the tunnel instead of an address: traffic arriving over the network Flui built is accepted on those ports, and traffic arriving any other way is not. This keeps working when the other end’s address changes, which an address-based rule could not do.

Your telemetry ports are never public, not even briefly during setup. They are opened on the tunnel and nowhere else, and a cluster that has not joined the tunnel yet has simply not started sending.

The tunnel does not make your clusters neighbours. A machine accepts tunnel traffic addressed to itself and does not pass it along to anyone else. Two workload clusters on the same tunnel cannot reach each other through it.

One policy, two ways to enforce it

The policy above is the same everywhere. What changes is the mechanism available to enforce it.

One policy, two places to enforce it: the provider's firewall around the machines, or the Flui firewall inside each one.

Some providers run a firewall of their own in front of the machine, with an API Flui drives, and Flui uses it. Where there is no such firewall (and a Linux machine you already own has nothing in front of it at all), Flui applies the rules on the host itself, and the machine becomes its own perimeter. The provider table shows which providers have one.

Where the provider has an edge firewall, new workload clusters also get the same rules on each node, so a node left outside the provider firewall still exposes only SSH, HTTP, HTTPS and the Flui network. flui cluster host-firewall <cluster> shows it and turns it on or off.

Flui decides which of the two applies from the provider’s declared capabilities, never from its name, as the rest of the platform does. So nothing above changes when you move to a provider with no firewall API: flui env firewall apply is one command with one meaning, whatever mechanism runs behind it.

The firewall on a machine you own

This matters most when you install onto your own machine, because there the machine can really be exposed. Where the provider has an edge firewall, it exists before any node does, so the host is never reachable unprotected. A machine you already own is reachable from the moment the cluster binds a port, unless something closes it first.

So Flui applies the host firewall before the cluster starts, as part of the install. Everything inbound is denied by default; SSH, HTTP and HTTPS are opened; the ports the nodes use to talk to each other, and the port range used for service traffic inside the cluster, are reachable only from the cluster’s own private ranges and never from the internet. The ruleset is written to the machine and re-applied when it restarts, so a reboot does not undo it.

The installation is not reported ready until that is in place, because an install that leaves the machine open to the internet has not succeeded.

One rule is not narrowed: SSH stays reachable from any address. A cloud machine has an out-of-band console you can fall back on when a firewall change locks you out. A machine you own usually does not, so a wrong SSH allow-list there can lock you out for good, and Flui will not take that risk for you. Restrict port 22 at your provider’s edge, or in the machine’s own SSH configuration, where you keep a way back in.

This is also why flui env update-firewall behaves differently here. There is no provider firewall to change, so it says so instead of failing, and points you to the two commands below.

Applying and inspecting the host firewall

Two commands, both acting on the installation’s own cluster:

flui env firewall apply
flui env firewall status

apply makes sure a firewall exists and then applies it. If the cluster has none, it seeds the default rules for that kind of cluster first. It is idempotent: running it again is safe, and it fixes most of what can go wrong here.

status reads it back: whether a firewall is configured at all, the reconciliation state, when it was last applied, and the inbound rules in force. If there is none, it says that nothing is filtering inbound traffic and tells you to apply one.

It also reports drift, which means the rules Flui wants differ from the rules it last managed to apply, for example after an update that failed halfway or a provider call that did not land. Drift compares Flui’s own records; it is not a live scan of the machine. flui env firewall apply fixes it.

One failure looks worse than it is. If the install applies the firewall to the machine but cannot register it with the control plane, the machine is still protected: the rules are on it and active. What is missing is Flui’s record of them, and without it Flui cannot reconcile the firewall or report drift on it. Run flui env firewall apply afterwards to close that gap.

When an agent asks for this, it stops and asks you first: the firewall decides what can reach the cluster from outside, including your own access to it. See The action cycle.

How the firewall tracks the cluster

The firewall is created with the cluster and lasts as long as the cluster. Three moments matter:

• At cluster creation, where the provider has an edge firewall, it is created before the master server or in the same step, so the master is never briefly reachable on the public internet without protection. On a machine you own, the same guarantee comes from applying the rules on the host before the cluster starts.
• When a worker is added, the firewall is applied to it before the node carries traffic, so a new node is never exposed.
• When a worker is removed, the server is deleted at the provider, where there is one, and the firewall’s record of covered nodes is updated. The firewall itself stays in place for the remaining nodes.

You do not have to manage any of this: it is part of how nodes join and leave a cluster, described in Nodes and cluster topology.

The provider abstraction

The firewall is one of the dimensions Flui’s provider abstraction covers. Each integrated provider implements the same Flui-side contract (create, update, apply, remove), and the provider integration absorbs the differences in rule shape and direction semantics. The host firewall is one more implementation of that contract, reached over SSH instead of an API. Either way, the cluster sees one neutral firewall model.

Where this chapter goes from here

• Creating a cluster from zero: where the firewall is created.
• Get Flui running: installing onto a machine you already own, step by step.
• VNets and subnets, abstracted: the private network the firewall does not filter.
• How Flui works across providers: why firewall capability is one of the dimensions a provider can expose or lack.