Stratum PRO

Stratum PRO is the same engine with fleet management on top. It is not a fork and not a different distribution: a PRO cluster and a Stratum cluster are built by the same engine, from the same command tree.

What PRO adds is almost entirely above one cluster — managing many of them from one place, signing in through your identity provider, and provisioning new ones. The one thing it adds inside a cluster is the CIS hardening profile, which the engine carries a seam for and PRO supplies; the rest of this page says where that line falls and why.

Stratum and Stratum PRO

Everything in the top half of that table except the CIS profile is in the open-source engine and always has been. The CIS profile is the one capability inside the cluster that a PRO licence carries: the engine keeps every security control that is on by default, and keeps the mechanism a hardened profile is built on, but the vetted CIS profile itself, the hardening check auditor and the compliance documentation ship with PRO. The engine's --cis flag is deprecated and goes away once PRO carries the profile; a node that was started with it keeps working through an in-place upgrade to the PRO binary. See Where the line falls.

One binary

A PRO install ships a binary of its own, also invoked as stratum. It is built from the same engine command tree, with two more subcommands:

stratum fleet-manager    # the hub
stratum fleet-agent      # a member

Nothing is forked and no existing command changes. PRO imports one package from the open-source project — its command tree — and adds those two subcommands to it.

One command does not cross: stratum dash is registered by the open-source entrypoint rather than by the shared command tree, so the PRO binary does not carry it. That is deliberate — it would compile the dashboard's server, proxy and embedded single-page app into every PRO install. PRO's equivalent is the hub in standalone mode. The in-cluster dashboard is different: it is a stack the shared engine stages, so a PRO cluster runs it too unless spec.dashboard.enabled is false.

stratum mcp goes the other way. It is registered inside the shared command tree rather than beside it, so a PRO install serves the Model Context Protocol on the same terms an open-source one does, and the tier flags mean the same thing in both.

Every other part of PRO's fleet management reaches the cluster the same way any other workload would: through the Kubernetes API.

That is the reason a cluster does not know whether it is a fleet member. Fleet membership is something a cluster joins, not something it is built as. The CIS profile is different in kind: a node that runs it is built with it, by a binary that carries it, which is why it belongs to the binary and not to the fleet.

Fleet management

One hub, many members. The hub serves an API, a dashboard, and a proxy to each member's Kubernetes API; a member runs an agent that registers once and then holds the connection open.

The hub installs into the stratum-fleet namespace and adds two custom resources:

Joining a cluster

A member can join in either direction, which matters more than it sounds:

• The member connects out. You mint a registration token on the hub, apply the generated manifest on the member, and its agent opens a tunnel back. The agent lands in the stratum-fleet-agent namespace. Nothing needs to route to the member, so this works from behind NAT and through a firewall that allows only outbound traffic.
• The hub connects in. You give the hub a kubeconfig for the member instead. No agent is installed, and the trust direction inverts — the hub now holds a credential for that cluster.

Registration tokens are single-use and short-lived: one hour by default, capped at twenty-four, and the manifest URL returns 404 once redeemed. A token is issued against a profile — full, which binds the agent to a purpose-built ClusterRole rather than cluster-admin, or readonly. The profile is fixed at mint time; a readonly token cannot be redeemed for a full bundle.

Running the dashboard without a fleet

The hub has a standalone mode: the same binary and the same image, serving one cluster, installed into the stratum-dash namespace with no custom resources, no registration endpoints and no tunnel server. It is a reasonable way to run the dashboard on a single cluster. The engine's own in-cluster dashboard, in the stratum-dashboard namespace, does the same job with nothing to install; turn it off with spec.dashboard.enabled: false when the hub serves the cluster instead.

Single sign-on

The hub authenticates against any OIDC provider and maps your identity provider's groups onto its two roles, admin and viewer.

Two limits worth knowing before you plan around SSO:

• A session lasts 12 hours and the lifetime is fixed — there is no flag to shorten it.
• Disabling a user at your identity provider stops them signing in again. It does not end a session they already hold, which can therefore survive for up to those 12 hours.

Provisioning new clusters

The hub can create clusters as well as adopt them, through ClusterAPI. This is opt-in twice over: the hub must be started with --capi, and the provisioning permissions ship as a separate manifest rather than in the base install.

Where the line falls, and why

The split is not a pricing exercise applied after the fact — it follows from how the engine is built, and two examples show it.

The Helm chart API stays open source. In Stratum the operator is the manifest deployer: it is what installs the CNI, cluster DNS and the default StorageClass. Moving it behind a licence would take all three with it, and the open-source build would no longer reach Ready on its own. So it stays.

The certificate approver stays open source too. A hardened profile issues kubelet serving certificates through the CSR flow and the operator runs their approver. The approver is a mechanism every profile may use, so it stays; so do --kubelet-certificate-authority, the TLS cipher suites, profiling off, kubelet anonymous auth refused, etcd TLS and front-proxy trust, which are on in every cluster whatever its profile.

The CIS profile is the exception, and it is a deliberate one. This is the design the current releases are moving to; the release notes say how far each one has got. The engine exposes a profile seam: an importer such as the PRO binary registers a named profile that declares extra apiserver flags, kubelet settings, config files, shared secrets and sysctls, and the engine renders, carries and backs up whatever it is given. Once the move is complete the engine ships no profile of its own; until then it still carries the CIS profile behind --cis, which is deprecated. The CIS profile, with its audit policy, encryption at rest, PodSecurity restricted admission and the hardening check auditor that verifies it, is content PRO maintains against the CIS Kubernetes Benchmark and supports. A node that names a profile its binary does not carry refuses to start rather than silently running without it.

The rule those cases describe: anything a single cluster needs in order to be a correct, secure Kubernetes cluster is open source, and so is every mechanism a profile is built from. A compliance profile, and the proof that a cluster meets it, is PRO.