Exclusive Access · Invitation Only

Security

What Stratum protects on its own, what you need to set up yourself, and what it deliberately does not protect against. The last part matters most: assuming a boundary exists where it does not is how people get hurt.

Protected without any setup

You do not need to configure any of this.

  • The management API is closed until you open it. It will not serve requests without a token, and there is no insecure fallback.
  • The API is encrypted. There is no unencrypted way in.
  • Repeated failed sign-ins are locked out, and an attacker cannot turn that lockout into a way of denying access to a legitimate user.
  • Configuration and licenses are verified before they are trusted. Anything altered in transit, or issued by anyone other than Cenvero, is refused — checked on the node itself, so it works offline.
  • Workloads cannot impersonate each other. Traffic from a workload must match what that workload is registered as. This is enforced on every packet.
  • Changes made outside Stratum are undone. If something alters an interface Stratum manages, it is put back.
  • Cluster members prove who they are to each other. Each member has its own identity, issued by its cluster; the cluster port admits no one else but a new node bringing a valid join code, and a removed member is refused from that moment. A request passed from one member to another carries who asked and from which address, never their key or password, and the member that does the work applies its own licence, tenant rules and address allowlist. A join code works once and expires. See Clustering Overview.
  • The node's records are private. Other local accounts and plugins cannot read the node's records, and cannot list /var/lib/cenvero-str/, the directory that holds them. A node installed with an earlier version is corrected when the agent starts.
  • A cluster member's address is never blocked. Intrusion detection and per-source connection limits never block it, so forged traffic cannot cut the members off from each other, and a rule from rules add or rules batch, or a firewall deny rule, that would block it is refused. A block shared with a cluster ends at the same moment on every member. See Clustering Overview.
  • Every change is recorded. The node's audit log records every change made through the API, the web console, the tenant portal or the command line — who, from where, on what, and whether it succeeded, failed or was refused — along with sign-ins and consoles opened. No record holds a key, token or password. Each record is linked to the one before it by a fingerprint, so a record altered or removed afterwards is detected by cenvero-str-ctl audit verify. See Monitoring.

Your checklist

None of this happens on its own.

Deny by default in the firewall. Until you do, traffic matching no rule is allowed. See Firewall.

Treat the API token as a credential. It grants full control of the node. Create it at install time, keep it out of shell history and version control, and replace it if it may have been exposed.

Limit who can reach the API. It can be restricted to specific addresses (api_allowed_ips). An API reachable from the internet is a mistake even with a strong token — keep it on your management network. In a cluster, each member applies its own list to your address, also when you reach it through another member, and refuses what it does not accept. So a member with a narrower list stays protected, but give every member a list that includes the addresses you manage the cluster from. A member that refuses your address still shows its machines and networks in the other members' lists; see Clustering Overview.

Keep the management network private. Stratum assumes only your operators can reach it. In a cluster, open the cluster port (TCP 7073) between the members only.

Protect every cluster member as the whole cluster. An API token or operator key a member accepts reaches every member through it, and root on any member can administer the cluster. Keep join codes like passwords until they are used, and revoke the ones you no longer need.

Keep nodes updated. Updates are pulled, never pushed, so a node nobody updates stays vulnerable. See Upgrades.

Back up /etc/cenvero-str/ and /var/lib/cenvero-str/. They are what a node needs to come back as itself.

Available if you want it

  • Stricter interface protection. By default an unauthorised change to a managed interface is undone shortly after it happens. On a suitably configured kernel it can be refused outright instead. Off unless you enable it.
  • Client certificates on the gRPC health-check port, in addition to a token.
  • Intrusion detection, surfacing scanning and flooding patterns. Off by default.

What is not protected

Someone with root on the node. The design protects against what arrives over the network, not against an administrator of the machine itself. Anyone with root can stop or replace what is running there. Verification exists to stop a remote attacker substituting configuration or licenses — it does not, and cannot, constrain someone who already owns the box.

Interface protection is repair, not prevention. By default a change is detected and undone, so there is a window where it applied. Treat it as tamper-evidence with automatic repair rather than a lock.

The audit log is tamper-evident, not tamper-proof. Removing or changing a record breaks its chain, and audit verify says where. But someone with root on the node could rewrite the whole log consistently. Keep the record number and hash that audit verify prints somewhere off the node and check them later (audit verify --checkpoint <number>:<hash>), or export the log off the node on a schedule.

Plugins are trusted code. Signing proves a plugin is genuinely the one its developer published and has not been altered since. That is authenticity, not a verdict on what the code does. A plugin runs sandboxed as an unprivileged user, which limits what it can reach, but a sandbox is a mitigation, not a guarantee against a hostile plugin. Only install plugins from sources you trust. See Installing Plugins.

A frozen license is not a security control. It blocks changes; traffic keeps flowing. To take a node out of service, isolate it on the network.

A cluster trusts each of its members. Every member holds what it takes to admit new members, so one compromised member puts the whole cluster at risk until it is removed and the cluster's certificate authority is replaced (below).

Existing connections survive a rule change. Tightening a rule governs new connections; conversations already open continue until they end. If you are cutting traffic off during an incident, clear them explicitly — see Firewall.

If a node may be compromised

  1. Isolate it on the network, upstream — not using the node's own firewall.
  2. Remove the node from your account: Nodes, then More › Remove node on its row. At its next licence check it stops being licensed, which stops it making changes; it does not stop traffic.
  3. If it is a cluster member, take it out of the cluster from another member: cenvero-str-ctl cluster remove <node id> (the others refuse it at once, and this works whatever the licences say), revoke the join codes that have not been used (cluster join-code list, then cluster join-code revoke <id>), and replace the cluster's certificate authority with cluster ca rotate.
  4. Collect evidence before restarting anything. Logs are in /var/log/cenvero-str/. Export the audit log (cenvero-str-ctl audit export --output audit.jsonl), copy it off the node, and run cenvero-str-ctl audit verify, with the checkpoint you kept if you have one. Restarting is the first instinct and it can cost you the answer.
  5. Replace the API token and any tenant keys the node held.
  6. Rebuild rather than clean up. If root was obtained, reinstall.

Reporting a security issue

Report it to us privately through the contact form rather than publicly, with enough detail to reproduce it.

Where to go next

↓ This page as JSON ↓ All documentation as JSON