3 publicaciones etiquetados con "Seguridad"

La mayoría de las formas de poner autenticación delante de un almacén de datos distribuido acaban por añadir un segundo sistema distribuido para hacerla funcionar: un servicio de autenticación al que llamar, una base de datos de sesiones que replicar, un endpoint de introspección de tokens que cada nodo tiene que alcanzar en la ruta caliente. Aseguraste el almacén y te compraste una nueva dependencia de disponibilidad y una nueva fuente de latencia.

Zaris toma una ruta distinta, y es una deliberadamente aburrida: una clave de firma por clúster, y tokens que cualquier nodo puede verificar por sí mismo. Un token es un JWT firmado con la clave privada del clúster; cada manager y cada nodo tiene la mitad pública y comprueba la firma sin conexión — sin llamada a un servidor de autenticación, sin quórum, sin consulta a una base de datos. La seguridad está desactivada por defecto, y un clúster con ella desactivada se comporta exactamente como uno no asegurado. Esta entrada trata de qué se activa cuando lo enciendes: la forma del token, el modelo de roles-y-ámbitos, los dos planos donde realmente ocurre la aplicación y — porque fingir lo contrario es cómo la gente adquiere una falsa sensación de seguridad — los bordes operativos que es fácil equivocar.

La forma más rápida de asegurarte de que TLS se omita es forzar un único modelo de confianza sobre todos. Un desarrollador que ejecuta un almacén en una laptop no quiere levantar una CA. Un banco con una raíz offline en un HSM no quiere que tu herramienta acuñe certificados en absoluto. Entrega un almacén que solo conozca uno de esos casos, y la mitad de tus usuarios desactivarán la seguridad para poder trabajar.

Por eso Zaris no elige por ti. Su confianza TLS es enchufable a lo largo de cuatro modos de autoridad certificadora, desde el autofirmado sin configuración hasta certificados que aprovisionas enteramente fuera de banda. Eliges el modo que coincide con la PKI que ya ejecutas, y Zaris encaja en ella en lugar de pedirte que la reconstruyas a su alrededor. TLS no es una talla única, y tratarlo así es exactamente por qué la seguridad se pospone.

Llevar un almacén distribuido a Kubernetes es fácil. Llevarlo ahí con TLS activado, alcanzable desde fuera del clúster, y un cliente que realmente se conecta es donde la mayoría de los recorridos se detienen silenciosamente. Zaris incluye un chart de Helm, y hemos validado todo el camino — incluida la configuración asegurada y alcanzable externamente — de extremo a extremo en un clúster local.

Este post es ese recorrido. Lo ejecutamos en kind (Kubernetes-in-Docker) para que puedas reproducir cada paso en una laptop, y tomamos el camino más difícil a propósito: TLS habilitado, certificados con los subject alternative names correctos, acceso externo activado, y un cliente conectándose por el endpoint asegurado. A esto lo llamamos la configuración Model B — alcanzable externamente y asegurada, frente a un clúster solo interno.

Una regla de corrección hace tropezar a casi todos los primeros despliegues, y no tiene nada que ver con los certificados: el nombre del almacén en tu connection string debe ser igual al clusterId del despliegue. Señalaremos exactamente dónde muerde eso. Todo lo demás es idéntico en un clúster de producción — kind solo nos da un lugar limpio y desechable para demostrarlo.