3 articles tagués avec « Sécurité »

La plupart des façons de placer de l'authentification devant un store de données distribué finissent par ajouter un second système distribué à faire tourner : un service d'authentification à appeler, une base de données de sessions à répliquer, un point de terminaison d'introspection de jetons que chaque nœud doit atteindre sur le chemin chaud. Vous avez sécurisé le store et vous vous êtes acheté une nouvelle dépendance de disponibilité et une nouvelle source de latence.

Zaris prend une autre route, et c'est délibérément une route ennuyeuse : une clé de signature par cluster, et des jetons que chaque nœud peut vérifier par lui-même. Un jeton est un JWT signé avec la clé privée du cluster ; chaque manager et chaque nœud détiennent la moitié publique et vérifient la signature hors ligne — aucun appel à un serveur d'authentification, aucun quorum, aucune recherche en base de données. La sécurité est désactivée par défaut, et un cluster avec elle désactivée se comporte exactement comme un cluster non sécurisé. Cet article traite de ce qui s'active quand vous l'activez : la forme du jeton, le modèle de rôle-et-portée, les deux plans où l'application se produit réellement, et — car prétendre autrement est la façon dont les gens se donnent un faux sentiment de sécurité — les limites opérationnelles faciles à rater.

Le moyen le plus sûr de garantir que TLS sera contourné est d'imposer un unique modèle de confiance à tout le monde. Un développeur qui exécute un store sur un ordinateur portable ne veut pas monter une CA. Une banque dont la racine hors ligne est dans un HSM ne veut pas du tout que votre outil frappe des certificats. Livrez un store qui ne connaît qu'un seul de ces cas, et la moitié de vos utilisateurs désactiveront la sécurité pour faire leur travail.

Zaris ne choisit donc pas à votre place. Sa confiance TLS est enfichable selon quatre modes d'autorité de certification, du self-signed zéro-configuration jusqu'aux certificats que vous provisionnez entièrement hors bande. Vous choisissez le mode qui correspond à la PKI que vous exploitez déjà, et Zaris s'y insère au lieu de vous demander de tout reconstruire autour de lui. TLS n'est pas une solution universelle, et le traiter ainsi est précisément la raison pour laquelle la sécurité est repoussée.

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.