Administration Archives - Alexandre Vazquez

Descubriendo la Verdad Detrás de los Secretos de Kubernetes — Foto por krakenimages en Unsplash

Hemos estado hablando recientemente sobre ConfigMap como uno de los objetos para almacenar una configuración diferente para cargas de trabajo basadas en Kubernetes. Pero, ¿qué pasa con los datos sensibles?

Esta es una pregunta interesante, y la respuesta inicial de la plataforma Kubernetes fue proporcionar un objeto Secrets. Basado en su definición del sitio web oficial de Kubernetes, definen los secretos de esta manera:

Un Secret es un objeto que contiene una pequeña cantidad de datos sensibles como una contraseña, un token o una clave. Tal información podría de otro modo ser puesta en una especificación de Pod o en una imagen de contenedor. Usar un Secret significa que no necesitas incluir datos confidenciales en el código de tu aplicación

Entonces, por defecto, los secretos son lo que deberías usar para almacenar tus datos sensibles. Desde la perspectiva técnica, para usarlos, se comportan de manera muy similar a ConfigMap, por lo que puedes vincularlo a las diferentes variables de entorno, montarlo dentro de un pod, o incluso tener usos específicos para gestionar credenciales para diferentes tipos de cuentas como Cuentas de Servicio. Esto clasifica los diferentes tipos de secretos que puedes crear:

Opaco: Esto define un secreto genérico que puedes usar para cualquier propósito (principalmente datos de configuración o archivos de configuración)
Token de Cuenta de Servicio: Esto define las credenciales para cuentas de servicio, pero esto está obsoleto y ya no se usa desde Kubernetes 1.22.
Credenciales de Registro Docker: Esto define credenciales para conectarse al registro Docker para descargar imágenes como parte de tu proceso de implementación.
Autenticación Básica o SSH: Esto define secretos específicos para manejar la autenticación.
Secreto TLS:
Secretos de Arranque:

Pero, ¿es seguro usar Kubernetes Secrets para almacenar datos sensibles? La respuesta principal para cualquier pregunta en cualquier tema relacionado con la tecnología es: Depende. Pero ha surgido cierta controversia que este tema también se cubre en la página oficial de Kubernetes, destacando los siguientes aspectos:

Los Secrets de Kubernetes se almacenan, por defecto, sin cifrar en el almacén de datos subyacente del servidor API (etcd). Cualquiera con acceso a la API puede recuperar o modificar un Secret, y también cualquiera con acceso a etcd. Además, cualquiera que esté autorizado para crear un Pod en un espacio de nombres puede usar ese acceso para leer cualquier Secret en ese espacio de nombres; esto incluye acceso indirecto como la capacidad de crear un Deployment.

Entonces, lo principal es que, por defecto, esta es una forma muy, muy insegura. Parece más una categorización de los datos que un manejo seguro adecuado. Además, Kubernetes proporciona algunos consejos para intentar hacer esta alternativa más segura:

Habilitar el Cifrado en Reposo para los Secrets.
Habilitar o configurar reglas RBAC que restrinjan la lectura de datos en los Secrets (incluyendo medios indirectos).
Cuando sea apropiado, también usar mecanismos como RBAC para limitar qué principales tienen permitido crear nuevos Secrets o reemplazar los existentes.

Pero eso puede no ser suficiente, y eso ha creado espacio para que terceros y proveedores de la nube ofrezcan su solución que cubra estas necesidades y al mismo tiempo también ofrezca características adicionales. Algunas de estas opciones son las que se muestran a continuación:

Sistemas de Gestión de Claves en la Nube: Prácticamente todos los grandes proveedores de la nube proporcionan alguna forma de Gestión de Secretos para ir más allá de estas características y mitigar esos riesgos. Si hablamos de AWS, está AWS Secrets Manager , si hablamos de Azure, tenemos Azure Key Vault , y en el caso de Google, también tenemos Google Secret Manager.
Sealed Secrets es un proyecto que intenta extender los Secrets para proporcionar más seguridad, especialmente en el enfoque de Configuración como Código, ofrece una forma segura de almacenar esos objetos en el mismo tipo de repositorios que expones cualquier otro archivo de recursos de Kubernetes. En sus propias palabras, “El SealedSecret solo puede ser descifrado por el controlador que se ejecuta en el clúster de destino, y nadie más (ni siquiera el autor original) puede obtener el Secret original del SealedSecret.”
Gestores de Secretos de terceros que son similares a los de los Proveedores de la Nube que permiten un enfoque más independiente, y hay varios jugadores aquí como Hashicorp Vault o CyberArk Secret Manager
Finalmente también, Spring Cloud Config puede proporcionar seguridad para almacenar datos que están relacionados con conceptos de configuración sensibles como contraseñas y al mismo tiempo cubre la misma necesidad que proporciona ConfigMap desde una perspectiva unificada.

Espero que este artículo haya ayudado a entender el propósito de los Secrets en Kubernetes y, al mismo tiempo, los riesgos respecto a su seguridad y cómo podemos mitigarlos o incluso confiar en otras soluciones que proporcionen una forma más segura de manejar esta pieza crítica de información.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Estamos viviendo tiempos en los que se escucha hablar de DevOps en todas partes, cómo se deben eliminar las barreras entre estos dos mundos como Desarrollo y Operaciones, pero todos estos discursos se basan en el punto de vista del desarrollador y del negocio, pero nunca desde el punto de vista del Administrador.

Venimos de una época en la que los equipos de operaciones estaban divididos en varios niveles de escalamiento donde cada nivel debía estar menos poblado y más capacitado que el anterior. Así que tenemos un primer nivel con personas con conocimientos básicos que trabajan 24×7 cubriendo cualquier tipo de incidente que pudiera ocurrir. En caso de que ocurra algo, intentan resolverlo con el conocimiento (generalmente más documento que conocimiento…) y en caso de que algo no funcione como se espera, lo derivan a un segundo nivel con más conocimiento sobre la plataforma donde probablemente sean un equipo de guardia para manejar eso y vamos a tener tantos niveles como se desee. ¿Cómo encaja todo esto con DevOps, CI & CD y demás…? Ok, bastante fácil…

El Nivel 1 hoy en día no existe: Las herramientas de monitoreo, CI & CD y demás, hacen innecesario este primer nivel, porque si puedes crear un documento con los pasos a seguir cuando algo sale mal, estás escribiendo código pero dentro de un Documento, así que nadie te detiene para entregar una herramienta automatizada para hacer eso. Entonces, en inglés sencillo, los operadores de primer nivel de ayer ahora son scripts. Pero todavía necesitamos nuestros equipos de operaciones, nuestro servicio 24×7 y demás… seguro, porque de vez en cuando (más a menudo de lo que nos gustaría) sucede algo fuera de lo normal y eso necesita ser gestionado.

Entonces, la automatización nunca va a reemplazar a L2 & L3, así que vas a necesitar personas capacitadas para manejar incidentes, tal vez podrías tener un equipo más pequeño a medida que automatizas más procesos, pero nunca puedes deshacerte de la parte del conocimiento, ese no es el punto. Aquí, podemos discutir si este equipo podría ser el equipo de desarrollo o un equipo mixto de ambos mundos, y eso podría ser correcto. Cualquier enfoque es válido con esto. Así que, hemos implementado todos nuestros nuevos y elegantes procesos de CI & CD, herramientas de monitoreo y las plataformas parecen estar funcionando sin ninguna ayuda y soporte hasta que algo realmente extraño sucede. Entonces, ¿qué hacer con esa gente? Por supuesto, enseñar las habilidades para ser valiosos como L2 & L3, así que tienen que ser mejores operadores / administradores de sistemas / cualquier palabra que más te guste. ¿Y cómo pueden hacer eso?

Como dije antes, estamos pasando de un mundo donde los equipos de Operaciones trabajan basados en procedimientos escritos y tienen su imaginación limitada para mirar más allá de su protocolo aprobado, pero eso ya no es la forma en que L2 & L3 trabaja. Cuando te enfrentas a un incidente, el procedimiento es bastante similar a cazar un error, o si escapamos del mundo de TI, es como resolver un crimen. ¿Cuáles son las similitudes entre resolver un crimen y gestionar una plataforma? Ok, enumerémoslas:

– ¿Qué? — ¿Qué le pasó a mi sistema? Comienzas con las consecuencias del problema, probablemente un rastro de error en el registro, probablemente otro sistema llamándote porque tu sistema no está disponible… Ok, aquí lo tienes, este es tu cadáver.
¿Cuándo? — Cuando sabes que algo salió mal, comienzas a encontrar la causa raíz, y comienzas a buscar rastros de registros para encontrar el primero que generó el problema, incluso descartas los rastros de registros que son consecuencias del primero, y tratas de encontrar cuándo todo comenzó a fallar. Para hacer eso, necesitas buscar evidencias sobre el fallo y demás… Así que ahora, estás investigando, buscando evidencias, hablando con testigos (sí, tus rastros de registros son los testigos más confiables que vas a encontrar, rara vez mienten. Es como si estuvieran en el estrado frente a un juez)
….. ¿Y ahora? ¿Cómo & Por qué? — Y ese es el punto difícil, cómo & por qué, son los siguientes pasos como lo haces en una caza de errores, pero la principal diferencia aquí, es cuando el equipo de desarrollo está cazando un error, pueden correlacionar las evidencias que recopilan en el paso dos, con el código fuente que construyeron para saber cómo y por qué todo salió mal… Pero en tu caso, como administrador de sistemas probablemente te enfrentas a un sistema propietario o no tienes acceso al código o cómo enfrentarlo incluso si fuera de código abierto… y probablemente ni siquiera tienes acceso al código fuente del equipo de desarrollo… Entonces, ¿cómo resuelves esto?

Ok, probablemente la mayoría de ustedes están pensando algo como: Conocer el producto y tu plataforma. Ser un operador certificado del producto que estás gestionando, conocer todo el manual del producto, y demás… Y eso podría ser útil, porque eso significa que sabes mejor cómo funcionan las cosas a un nivel alto… pero… seamos claros: ¿Alguna vez encontraste en un curso de certificación, o examen o documentación o lo que sea, información de tan bajo nivel que podría ayudarte en el caso específico que estás enfrentando…? En caso de que la respuesta a mi pregunta sea sí, tal vez no estás enfrentando un error difícil, sino un error de configuración principal…
Entonces… ¿qué podemos hacer? Como dice el título: Aprende a programar. Pero probablemente estás pensando, ¿cómo puede estar relacionado saber programar con cazar un error cuando no tengo acceso al código ni siquiera para echar un vistazo? Y… ¿aprender a programar en qué lenguaje? ¿en los componentes que se gestionan en mi plataforma? ¿en java? ¿en Go? ¿En node.js? ¿En C++? ¿En x86? ¿Todos ellos? Ok… tienes razón, tal vez la pregunta no es simplemente aprender a programar, pero esa es la idea: Aprende a programar, aprende a diseñar, aprende a arquitectar soluciones… ¿Quieres saber por qué? Ok, veamos. En toda mi carrera he estado trabajando con muchos productos diferentes, diferentes enfoques, diferentes paradigmas, diferentes lenguajes base, todo diferente, pero todos comparten una cosa, que todos los sistemas hoy en día comparten: Están construidos por personas.

Sí, cada pieza de software, cada servidor, cada programa, cada página web, cada todo está construido por una persona, como tú y como yo…

Si piensas que todos los productos y piezas de software están hechos por genios, estás equivocado. ¿Eres consciente de cuántas piezas de software están disponibles? ¿Crees que existen tantos genios en todo el mundo? Por supuesto, son personas capacitadas y algunas de ellas son realmente brillantes, y es por eso que generalmente siguen el sentido común para arquitectar, diseñar y construir sus soluciones.

Y ese es el punto que podemos usar para resolver nuestro caso y resolver nuestro asesinato, porque con las evidencias que tenemos y las ideas de construir soluciones, tenemos que pensar: Ok, ¿cómo habría construido esto si yo fuera el encargado de esta pieza de software? Y vas a ver que tienes razón casi todo el tiempo…

Pero me falta otro punto importante que dejamos sin respuesta antes… ¿Aprender a programar en qué lenguaje? En el que tu plataforma está basada: Si estás gestionando una plataforma basada en OSGi, aprende mucho sobre desarrollo en java y desarrollo y arquitectura OSGI, vas a encontrar que todos los problemas son lo mismo… Una dependencia entre dos módulos OSGI, y una sentencia Import-package que debería estar allí… la otra en la que alguien carga los paquetes o alguna sentencia Export-Package que debería estar allí…

Lo mismo, si estás ejecutando una aplicación de escritorio .NET, aprende mucho sobre desarrollo .NET y serás lo suficientemente capacitado para no necesitar un documento para saber qué hacer, porque sabes cómo debería funcionar esto… y eso te llevará a por qué está sucediendo esto.

Y con todas esas preguntas respondidas, solo queda una cosa. Necesitas poner en marcha un plan para mitigar o resolver el problema, para que el problema nunca vuelva a suceder. Y con todo eso, presentamos nuestra orden de arresto al incidente.

Finalmente estás en la parte del juicio, cuando presentas tus evidencias, tu teoría sobre cómo y por qué sucedió esto (el motivo :P) y deberías poder convencer al jurado (el cliente) más allá de una duda razonable, y finalmente terminas con la sentencia que pediste para el error/fallo/incidente que es el plan de mitigación, y tu plataforma es un mundo mejor con un incidente menos caminando libre.

Lo que describimos aquí es cómo hacer un análisis post-mortem y probablemente para la mayoría de ustedes esto es algo diario que hacen, pero todo el tiempo en los clientes cuando trabajamos en colaboración con el equipo de operaciones, notamos que no siguen este enfoque, por lo que están atascados porque no tienen un documento que nos diga cómo hacer (paso a paso) en estas situaciones extrañas.

Así que, me gustaría terminar con un himno para resumir todo esto: Cuando te enfrentas a un incidente: «Mantén la calma, aplica el sentido común y comienza a leer los rastros de registros!!»