2 posts tagged with "Security"

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.

Getting a distributed store onto Kubernetes is easy. Getting it there with TLS on, reachable from outside the cluster, and a client that actually connects is where most walkthroughs quietly stop. Zaris ships a Helm chart, and we've validated the whole path — including the secured, externally-reachable configuration — end to end on a local cluster.

This post is that walkthrough. We run it on kind (Kubernetes-in-Docker) so you can reproduce every step on a laptop, and we take the harder road on purpose: TLS enabled, certificates with the right subject alternative names, external access on, and a client connecting over the secured endpoint. We call this the Model B configuration — externally-reachable and secured, versus an internal-only cluster.

One correctness rule snags almost every first deploy, and it has nothing to do with certificates: the store name in your connection string must equal the deployment's clusterId. We'll flag exactly where that bites. Everything else is identical on a production cluster — kind just gives us a clean, disposable place to prove it.