Aller au contenu principal

Déployer Zaris sur Kubernetes avec Helm : un tutoriel sécurisé de bout en bout

· 8 minutes de lecture
Clustron Team
Clustron Team
Ingénierie des systèmes distribués

Déployer Zaris sur Kubernetes avec Helm, sécurisé de bout en bout

Mettre un store distribué sur Kubernetes est facile. L'y mettre avec TLS activé, atteignable depuis l'extérieur du cluster, et un client qui se connecte réellement est là où la plupart des tutoriels s'arrêtent discrètement. Zaris fournit un chart Helm, et nous avons validé tout le chemin — y compris la configuration sécurisée et atteignable de l'extérieur — de bout en bout sur un cluster local.

Cet article est ce tutoriel. Nous l'exécutons sur kind (Kubernetes-in-Docker) afin que vous puissiez reproduire chaque étape sur un ordinateur portable, et nous prenons la route la plus difficile à dessein : TLS activé, certificats avec les bons subject alternative names, accès externe activé, et un client se connectant via le point d'accès sécurisé. Nous appelons cela la configuration Model B — atteignable de l'extérieur et sécurisée, par opposition à un cluster interne uniquement.

Une règle d'exactitude accroche presque chaque premier déploiement, et elle n'a rien à voir avec les certificats : le nom du store dans votre chaîne de connexion doit être égal au clusterId du déploiement. Nous signalerons exactement où cela mord. Tout le reste est identique sur un cluster de production — kind nous offre simplement un endroit propre et jetable pour le prouver.

Ce que « sécurisé » signifie ici​

Un déploiement Zaris est composé de plusieurs nœuds plus un manager, chacun atteignable à un nom DNS stable. Activer la sécurité signifie que trois choses s'alignent en même temps :

  1. TLS est activé sur les listeners des nœuds et du manager.
  2. Les certificats portent les bons SAN — chaque nom qu'un client pourrait utiliser pour atteindre un nœud doit figurer dans le certificat de ce nœud, sinon la vérification TLS échoue.
  3. L'accès externe est configuré afin qu'un client à l'extérieur du cluster atteigne les nœuds à un nom qui figure lui aussi dans le certificat.

L'exigence de SAN est la plus subtile. Un client vérificateur contrôle le certificat contre le nom qu'il a appelé, de sorte qu'un certificat à SAN unique ne couvrant que zaris-0 ne validera pas lorsqu'un client se connecte via un nom externe comme zaris.example.com. C'est pourquoi le chemin sécurisé utilise des certificats multi-SAN — un seul certificat valide pour le nom de service interne au cluster, le nom par pod et le nom externe.

Zaris fournit un outillage de génération de certificats et des exemples afin que cette étape soit reproductible plutôt qu'un marathon openssl artisanal. Vous pouvez toujours le faire à la main — la forme est ci-dessous — mais l'outillage garde l'ensemble des SAN correct à chaque fois.

Étape 1 : un cluster kind​

kind create cluster --name zaris-secure
kubectl cluster-info --context kind-zaris-secure
kubectl create namespace zaris

C'est tout le substrat. Sur un vrai cluster, vous sauteriez cette étape et pointeriez kubectl vers votre plan de contrôle managé ; rien en aval ne change.

Étape 2 : générer des certificats multi-SAN​

Les certificats doivent couvrir chaque nom qu'un client ou un pair utilisera : le nom de service interne au cluster, le nom stable par pod, et un nom externe que nous exposerons. L'outillage de certificats Zaris génère une CA et des certificats de nœud avec exactement cet ensemble de SAN ; voici la forme équivalente de style openssl pour que vous voyiez ce qui est demandé :

# 1. A CA the client will trust
openssl req -x509 -newkey rsa:4096 -nodes -days 365 \
  -keyout ca.key -out ca.crt \
  -subj "/CN=Zaris Dev CA"

# 2. A node certificate whose SANs cover EVERY name used to reach it
openssl req -newkey rsa:2048 -nodes \
  -keyout zaris-node.key -out zaris-node.csr \
  -subj "/CN=zaris"

cat > san.cnf <<'EOF'
subjectAltName = @alt
[alt]
DNS.1 = zaris-0.zaris.svc            # per-pod stable name
DNS.2 = zaris.zaris.svc              # in-cluster service name
DNS.3 = zaris.example.com            # external name clients dial
EOF

openssl x509 -req -in zaris-node.csr \
  -CA ca.crt -CAkey ca.key -CAcreateserial \
  -extfile san.cnf -days 365 -out zaris-node.crt

Chargez la CA et la paire clé/certificat du nœud dans le namespace sous forme de secrets que le chart peut monter :

kubectl -n zaris create secret generic zaris-ca \
  --from-file=ca.crt=ca.crt

kubectl -n zaris create secret tls zaris-node-tls \
  --cert=zaris-node.crt --key=zaris-node.key

La règle à retenir : si un nom ne figure pas dans subjectAltName, un client vérificateur qui appelle ce nom rejette la connexion. Obtenez la liste des SAN correcte et TLS fonctionne tout simplement ; ratez-la et vous poursuivrez un échec de poignée de main qui ressemble à un problème réseau mais n'en est pas un.

Étape 3 : le fichier de valeurs (TLS + accès externe)​

Voici une ébauche de values.yaml pour le Model B — sécurité activée, accès externe activé, et les secrets de certificat de l'étape 2 câblés :

# values.yaml — Model B: secured + externally reachable
clusterId: zaris          # <-- remember this value for the connection string

replicaCount: 3

tls:
  enabled: true
  # CA clients must trust, and the node key/cert pair
  caSecret: zaris-ca
  certSecret: zaris-node-tls

external:
  enabled: true
  # the name clients outside the cluster will dial —
  # must also be a SAN on the node certificate
  advertisedHost: zaris.example.com

manager:
  tls:
    enabled: true
    caSecret: zaris-ca
    certSecret: zaris-node-tls

Deux champs font le gros du travail. tls.enabled: true active les listeners sécurisés et monte les certificats. external.enabled: true avec un advertisedHost rend les nœuds atteignables depuis l'extérieur — et advertisedHost est le même zaris.example.com que nous avons placé dans les SAN du certificat. Ces deux-là doivent concorder. Gardez aussi un œil sur clusterId : il vaut zaris ici, et vous en aurez besoin mot pour mot dans un instant.

Étape 4 : helm install​

helm install zaris oci://registry-1.docker.io/clustron/zaris \
  --version 2.0.0 \
  -n zaris \
  -f values.yaml

# watch the nodes come up
kubectl -n zaris rollout status statefulset/zaris
kubectl -n zaris get pods

Lorsque les pods sont prêts, vous disposez d'un cluster Zaris à trois nœuds, avec TLS activé et un point d'accès externe. Sur kind, atteignez-le avec un port-forward ; sur un vrai cluster, un Service LoadBalancer ou un ingress prend le relais.

kubectl -n zaris port-forward svc/zaris 7000:7000

Étape 5 : connecter un client — et la règle du clusterId​

Voici maintenant la partie qui fait trébucher les premiers déploiements. Une chaîne de connexion Zaris nomme le store auquel vous vous connectez, et face à un déploiement Helm ce nom de store doit être égal au clusterId du déploiement. Nous avons défini clusterId: zaris dans values.yaml, donc le nom du store dans la chaîne de connexion est zaris — pas my-store, pas le nom de release, pas le nom du Service. Le clusterId.

// The store segment MUST match values.yaml clusterId ("zaris").
// zariss:// selects TLS; ?ca= points at the CA we generated.
var connectionString =
    "zariss://zaris.example.com:7000/zaris?ca=file:./ca.crt";

await using var client = await ZarisClient.ConnectAsync(connectionString);
await client.PutAsync("greeting", "hello from a secured cluster");
var value = await client.GetAsync("greeting");

Si le nom du store et le clusterId divergent, la connexion échoue — et l'erreur peut ressembler à un problème d'authentification ou de routage plutôt qu'à un problème de nommage. Lorsqu'un déploiement Helm sécurisé refuse de se connecter et que les certificats sont en règle, c'est la première chose à vérifier : nom du store de la chaîne de connexion == clusterId. C'est l'échec de premier déploiement le plus courant que nous observons.

Notez le schéma : zariss:// (avec le s supplémentaire) sélectionne le point d'accès sécurisé, et ?ca=file:./ca.crt indique au client quelle CA faire confiance — celle que nous avons frappée à l'étape 2. L'hôte est le nom externe, raison pour laquelle il devait être un SAN.

De kind à la production​

Deux choses diffèrent sur un vrai cluster : l'accès externe devient un Service LoadBalancer ou un ingress avec un vrai DNS au lieu d'un kubectl port-forward, et les certificats proviennent de votre propre CA ou d'un émetteur comme cert-manager plutôt que d'une CA de développement. Ce qui ne change pas est l'essentiel — la règle des SAN (chaque nom qu'un client appelle doit figurer dans le certificat) et la règle de chaîne de connexion (le nom du store est égal au clusterId). Vous échangez un port-forward contre un LoadBalancer et une CA de développement contre une vraie, vous ne réarchitecturez pas le déploiement.

Pour aller plus loin​

Voilà un cluster Zaris sécurisé de bout en bout : installé avec Helm, TLS activé, certificats multi-SAN, accès externe, et un client connecté via le point d'accès chiffré. Pour approfondir le modèle de confiance — Zaris prend en charge plusieurs modes de CA afin que vous n'ayez pas à combattre la PKI de votre organisation — lisez Confiance TLS enfichable. Pour la référence complète du chart et les schémas de réseau de production, voir le guide de déploiement Kubernetes.