La sécurité intégrée, pas rajoutée
L'authentification, l'autorisation et le chiffrement font partie du store — un seul tissu de confiance couvrant le plan de données et la console, configurable store par store, sans service supplémentaire à exploiter.
Trois couches, un seul tissu
Un seul tissu de confiance intégré sécurise le trafic de nœud à nœud, les connexions clientes et le plan de gestion — le même modèle d'identité et d'autorisation dans tout le cluster.
Authentification
Jetons porteurs vérifiés hors ligne — le nœud contrôle la signature par rapport à une clé de cluster mise en cache, sans aller-retour vers un serveur d'authentification sur le chemin critique.
Autorisation
RBAC avec refus par défaut — les sujets reçoivent des rôles, les rôles accordent des autorisations sur les stores et les opérations d'administration. Rien n'est autorisé tant que ce n'est pas accordé.
Chiffrement
TLS mutuel entre nœuds et TLS en authentification serveur pour les clients, à travers quatre modèles d'autorité de certification et de confiance — activez-le store par store.
Des jetons, vérifiés hors ligne
Les clients présentent un jeton porteur ; le nœud vérifie sa signature par rapport à la clé publique mise en cache du cluster — sans appel à un serveur d'authentification sur le chemin de la requête. Gardez le jeton hors de la chaîne de connexion avec des références env: ou file:.
- Aucune dépendance à un serveur d'authentification sur le chemin critique
- Jetons générés par le gestionnaire ; limités en portée et expirants
- Indirection sûre — les secrets ne figurent jamais dans l'URL
zariss://n0:7861/store?token=env:ZARIS_TOKENTLS mutuel dans tout le cluster
Le gossip et la réplication de nœud à nœud fonctionnent en TLS mutuel ; le plan de données client est en authentification serveur, où le client vérifie le nœud et s'authentifie avec un jeton. Sur Kubernetes, le certificat feuille du nœud peut porter un certificat multi-SAN afin que les clients externes le valident aussi.
- TLS mutuel nœud ↔ nœud ; authentification serveur pour les clients
- Renouvellement automatique du certificat feuille avant expiration
- Activez-le store par store — le texte en clair reste la valeur par défaut pour le développement
Quatre modèles d'autorité de certification et de confiance
De l'émission automatique sans PKI au montage de certificats émis par votre propre autorité de certification — choisissez le modèle de confiance qui correspond à votre organisation.
M0 · Auto / colocalisé
Le gestionnaire génère une autorité de certification de cluster et émet automatiquement les certificats feuilles des nœuds. Aucune PKI à exploiter — idéal pour sécuriser rapidement.
M1 · Apportez votre propre autorité de certification
Fournissez votre propre autorité de certification racine ; le cluster en émet les certificats feuilles, de sorte que Zaris s'enchaîne à une confiance que vous exploitez déjà.
M2 · Autorité de certification intermédiaire
Émettez depuis une autorité intermédiaire sous votre racine d'entreprise ; les certificats feuilles présentent la chaîne complète jusqu'à la racine d'ancrage.
M3 · Certificats feuilles pré-émis
Montez des certificats feuilles et une autorité de certification émis en externe sous forme de secrets (p. ex. cert-manager). Zaris se contente de les charger et de les servir.
Configurez-le et auditez-le au même endroit
Initialisez l'autorité de certification du cluster, générez des jetons d'enrôlement, choisissez le modèle de confiance et consultez l'état TLS par nœud — le tout depuis la vue intégrée Sécurité et TLS.
Sécurisé par configuration, pas par projet
Activez les jetons, le RBAC et le TLS store par store — aucun service de sécurité sur mesure à construire, exploiter et maintenir à jour.