Pluggable TLS Trust: Four CA Modes for Locking Down Zaris

The fastest way to make sure TLS gets skipped is to force one trust model on everyone. A dev running a store on a laptop doesn't want to stand up a CA. A bank with an offline root in an HSM doesn't want your tool minting certificates at all. Ship a store that only knows one of those, and half your users turn security off to get their work done.

So Zaris doesn't pick for you. Its TLS trust is pluggable across four certificate-authority modes, from zero-config self-signed all the way to certificates you provision entirely out of band. You choose the mode that matches the PKI you already run, and Zaris slots into it instead of asking you to rebuild around it. TLS isn't one-size-fits-all, and treating it that way is exactly why security gets deferred.

The four modes at a glance

Every mode lands you in the same place: nodes present certificates, clients verify them against a trusted CA, traffic is encrypted. What differs is who issues the certificates and where the trust root lives. As you move from M0 to M3, Zaris does less of the issuance and you keep more control — pick the point where the trust boundary lands where your security team wants it.

Mode	Name	Who issues node certs	Root of trust
M0	Auto	Zaris	Zaris-generated CA
M1	BYO-CA	Zaris, under your CA	Your organization's CA
M2	Intermediate	Zaris, as an intermediate	Your offline root, via a Zaris intermediate
M3	Pre-issued	You (out of band)	Whatever minted the certs

M0 — Auto: zero-config TLS for dev and simple deployments

In Auto mode, Zaris generates its own CA and issues node certificates under it automatically. There's nothing to provision — bring the cluster up and the nodes already speak TLS to each other and to clients.

Choose it when: you're developing, running a demo, or standing up a simple deployment where operator and consumer are the same team — encryption on, no ceremony.

tls:
  enabled: true
  ca:
    mode: auto        # Zaris generates a CA and issues node certs

The trade-off is inherent to self-signed trust: clients must trust a CA that Zaris invented, which means distributing it to them. That's fine inside one team; it's the wrong model the moment certificates need to chain to something your clients already trust — which is what the next mode fixes.

M1 — BYO-CA: chain to a CA your clients already trust

Bring-your-own-CA mode is the workhorse for organizations that already run a corporate CA. You hand Zaris your CA, and Zaris issues node certificates under it, so every node's certificate chains up to a root your clients trust already — no new CA to distribute, no per-client trust-store surgery.

Choose it when: you have an existing corporate CA and want Zaris certificates under it. This is the most common production choice.

tls:
  enabled: true
  ca:
    mode: byo               # you provide the CA; Zaris issues node certs under it
    caCert: file:/etc/zaris/pki/org-ca.crt
    caKey:  file:/etc/zaris/pki/org-ca.key

You're giving Zaris an issuing key here, so treat those files like the secrets they are — mount them from your secret store, not a config repo.

M2 — Intermediate: delegated issuance with an offline root

Intermediate mode is for organizations that keep their root CA offline and delegate issuance to intermediates. Zaris operates as an intermediate CA under your root and presents the full chain — node certificate, then the Zaris intermediate, up to your root — so a verifying client can build the path back to a root it trusts, even though that root never comes near the cluster.

Choose it when: your posture says the root stays offline (often in an HSM) and issuance is delegated to scoped intermediates. Zaris becomes one of those, with an issuing scope you control, while the root stays locked away.

# Your offline root signs a Zaris intermediate (done once, off the cluster)
openssl x509 -req -in zaris-intermediate.csr \
  -CA root-ca.crt -CAkey root-ca.key -CAcreateserial \
  -extensions v3_intermediate -days 1825 \
  -out zaris-intermediate.crt

# The node must present the FULL chain: node -> intermediate -> root
cat zaris-node.crt zaris-intermediate.crt > zaris-node-fullchain.crt

tls:
  enabled: true
  ca:
    mode: intermediate
    intermediateCert: file:/etc/zaris/pki/zaris-intermediate.crt
    intermediateKey:  file:/etc/zaris/pki/zaris-intermediate.key
    # so clients can build the full path to your offline root
    chain: file:/etc/zaris/pki/zaris-intermediate-fullchain.crt

Full-chain presentation makes or breaks this mode: if a node presents only its leaf certificate, clients that don't already hold the intermediate can't build the path to the root and verification fails.

M3 — Pre-issued: you mint the certs, Zaris just uses them

Pre-issued mode is maximum control. You provision the node certificates yourself, entirely out of band, and Zaris performs no issuance at all — it loads and presents the certificates you give it. It never holds an issuing key because it never issues anything.

Choose it when: you're in a strict or regulated environment where certificates are minted by a dedicated system — a corporate PKI team, an HSM-backed pipeline, cert-manager with a controlled issuer — and no application may issue its own. Zaris fits by stepping out of the issuance business completely.

tls:
  enabled: true
  ca:
    mode: provided          # certs minted elsewhere; Zaris only presents them
    nodeCert: file:/etc/zaris/pki/node-fullchain.crt
    nodeKey:  file:/etc/zaris/pki/node.key
    trustBundle: file:/etc/zaris/pki/trust-bundle.crt

Because nothing is issued for you, the burden shifts entirely to your provisioning process: the certificates must already carry the right SANs for every name each node advertises, and you own their rotation.

An honest word on maturity

All four modes are a first-class config choice, not a fork of the build. Two are power-user routes: M2 (Intermediate) lives or dies on correct full-chain presentation (a leaf-only node fails verification for clients that lack the intermediate), and M3 (Pre-issued) puts SANs, key handling, and rotation entirely on your provisioning process, because Zaris issues nothing. M0 and M1 are the smooth on-ramps; reach for M2/M3 when your PKI demands them.

The point of four modes

The value isn't the count — it's that you can turn TLS on without fighting your PKI. Same store, four trust boundaries: encryption-for-free in dev, chain-to-your-corporate-CA in production, delegate under an offline root, or mint certs externally and hand them over. Security that fits the environment gets left on; security that fights it gets switched off.

Where to go next

To see a secured cluster stood up end to end — TLS on, multi-SAN certificates, external access, and a client connecting over it — read Deploying Zaris on Kubernetes With Helm. For the full configuration reference on each CA mode, see the CA trust modes guide.