Skip to main content
Hexr isolates tenants with a separate trust domain and a separate root CA per tenant. Not a label. Not a namespace filter. Not a WHERE tenant_id = ?. The difference matters because of what happens when someone tests it. A filter is code, and code has bugs. A separate trust anchor has no code path that could accidentally accept the wrong tenant — there is nothing shared to misconfigure.

​
What “shared root” looks like, and why it is not enough

A common arrangement gives every tenant a path prefix inside one trust domain:
That reads like isolation. It is not. Both chain to the same root, so an SVID minted for tenant A verifies perfectly well against tenant B’s trust bundle. Whatever keeps them apart is authorisation logic somewhere above the cryptography — and a security reviewer will find that in about a minute.

​
What Hexr does instead

Each tenant gets its own trust domain and its own root:
Different domains, different keys, no shared bundle. An SVID from one is not denied by the other — it is unverifiable, because the chain ends at a certificate the other side has never seen.
Both roots are issued and operated by Hexr’s control plane, so a tenant still does no SPIRE work. The separation is in the PKI, not in the customer’s operational burden.

​
Verify it yourself

Do not take this on trust — that would rather defeat the point. Mint an SVID in each trust domain and cross-verify.
1

Get each tenant's trust bundle

2

Mint one SVID per trust domain

3

Cross-verify — two must pass, two must fail

The second produces:
That error is the point. The chain terminates at a root the verifier has never heard of.

​
It is re-checked on a schedule

A property proven once and never re-checked is not a property, it is a memory. The control plane runs this cross-verification hourly as a Kubernetes CronJob and fails loudly if it ever stops holding. The check also validates its own preconditions before forming a verdict — that its tooling is present, that artefacts are non-empty, and that every SVID verifies against its own root — and reports “isolation NOT assessed” separately from “isolation failed”. A check that cannot tell “the answer is no” from “I could not ask” is worse than no check, because it burns the one signal you were relying on.

​
What this does and does not give you

Isolation you can test

Cross-tenant verification fails cryptographically, in a way a reviewer can reproduce on their own laptop in two minutes.

Independent compromise blast radius

A compromised root affects one tenant. There is no shared key whose loss affects everyone.

Not data isolation on its own

Separate trust domains isolate identity. Database and storage separation are distinct controls; see Threat model.

Not free of operational cost

Each tenant is a real root CA with a real lifecycle. Hexr carries that, which is the service — but it is work being done, not work eliminated.