Cómo inyectar secretos en pods para mejorar la seguridad con Hashicorp Vault en 5 minutos

Cómo inyectar secretos en pods para mejorar la seguridad con Hashicorp Vault en 5 minutos

Introducción

Este artículo cubrirá cómo inyectar secretos en Pods usando Hashicorp Vault. En artículos anteriores, cubrimos cómo instalar Hashicorp Vault en Kubernetes, configurar y crear secretos en Hashicorp, y cómo herramientas como TIBCO BW pueden recuperarlos. Sin embargo, hoy vamos a dar un paso más allá.

La razón por la cual inyectar secretos en pods es muy importante es que permite que la aplicación dentro del pod sea transparente en torno a cualquier comunicación con Hashicorp. Después de todo, para las aplicaciones, el secreto será solo un archivo regular ubicado en una ruta específica dentro del contenedor. No necesita preocuparse si este archivo proviene de un Secreto de Hashicorp o de un recurso totalmente diferente.

Este enfoque de inyección facilita el enfoque poliglota del ecosistema de Kubernetes porque libera cualquier responsabilidad de la aplicación subyacente. Lo mismo ocurre con enfoques de inyección como Istio o mucho más.

Pero, expliquemos cómo funciona este enfoque para inyectar secretos en Pods usando Hashicorp Vault. Como parte de la instalación junto al servidor de vault que hemos instalado (o varios si has hecho una instalación distribuida), hemos visto otro pod bajo el nombre de value-agent-injector, como puedes ver en la imagen a continuación:

Inyectar Secretos en Pods: Pod del Inyector de Vault

Este agente será responsable de escuchar los nuevos despliegues que realices y, basado en las anotaciones que tenga este despliegue, lanzará un sidecar junto a tu aplicación y enviará la configuración para poder conectarse al vault y descargar los secretos requeridos y montarlos como archivos dentro de tu pod como se muestra en la imagen a continuación:

Para hacer eso, necesitamos realizar varios pasos como parte de la configuración que vamos a incluir en las próximas secciones del artículo

Habilitando la Autenticación de Kubernetes en Hashicorp

Lo primero que necesitamos hacer en esta etapa es habilitar la Autenticación de Kubernetes en Hashicorp. Este método permite a los clientes autenticarse con un Token de Cuenta de Servicio de Kubernetes. Hacemos eso con el siguiente comando:

 Vault auth enable kubernetes

Vault acepta un token de servicio de cualquier cliente en el clúster de Kubernetes. Durante la autenticación, Vault verifica que el token de la cuenta de servicio sea válido consultando un endpoint de revisión de tokens de Kubernetes. Ahora, necesitamos configurar este método de autenticación proporcionando la ubicación de nuestra API de Kubernetes, y para hacer eso, necesitamos ejecutar el siguiente comando:

 vault write auth/kubernetes/config 
    kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443"

Definiendo una Cuenta de Servicio de Kubernetes y Definiendo una Política

Ahora, crearemos una Cuenta de Servicio de Kubernetes que ejecutará nuestros pods, y a esta cuenta de servicio se le permitirá recuperar el secreto que generamos en el artículo anterior.

Para hacer eso, comenzaremos con la creación de la cuenta de servicio ejecutando este comando desde fuera del pod:

kubectl create sa internal-app

Esto creará una nueva cuenta de servicio bajo el nombre de internal-app, y ahora vamos a generar una política dentro del servidor de Hashicorp Vault usando este comando dentro del pod del servidor de vault:

 vault policy write internal-app - <<EOF
path "internal/data/database/config" {
  capabilities = ["read"]
}
EOF

Y ahora, asociamos esta política con la cuenta de servicio ejecutando este comando también dentro del pod del servidor de vault:

  vault write auth/kubernetes/role/internal-app 
    bound_service_account_names=internal-app 
    bound_service_account_namespaces=default 
    policies=internal-app 
    ttl=24h

Y eso es prácticamente toda la configuración que necesitamos hacer en el lado de Vault para poder inyectar secretos en pods usando Hashicorp Vault. Ahora, necesitamos configurar nuestra aplicación en consecuencia haciendo las siguientes modificaciones:

  • Especificar el ServiceAccountName en el despliegue para que sea el que creamos previamente: internal-app
  • Especificar las anotaciones específicas para inyectar los secretos de vault y la configuración de esos secretos.

Comencemos con el primer punto. Necesitamos agregar el serviceAccountName a nuestro archivo YAML de Manifiesto de Kubernetes como se muestra a continuación:

Inyectar Secretos en Pods: Definición del Nombre de la Cuenta de Servicio

Y con respecto al segundo punto, lo resolveríamos agregando varias anotaciones a nuestro despliegue, como se muestra a continuación:

Inyectar Secretos en Pods: Anotaciones

Las anotaciones utilizadas para inyectar secretos en pods son las siguientes:

  • vault.hashicorp.com/agent-inject: ‘true’: Esto le dice al inyector de vault que nos gustaría inyectar el agente sidecar en este despliegue y tener la configuración de Vault. Esto es necesario para hacer cualquier configuración adicional
  • vault.hashicorp.com/role: internal-app: Este es el rol de vault que vamos a usar cuando solicitemos secretos e información al vault para asegurarnos de que solo accedemos a los secretos que hemos permitido según la política que creamos en la sección anterior
  • vault.hashicorp.com/agent-inject-secret-secret-database-config.txt: internal/data/database/config: Esta será una anotación por cada secreto que planeamos agregar, y se compone de tres partes:
    • vault.hashicorp.com/agent-inject-secret- esta parte es fija
    • secret-database-config.txt esta parte será el nombre del archivo que se crea bajo /vault/secrets dentro de nuestro pod
    • internal/data/database/config Este es el camino dentro del vault de nuestro secreto para ser vinculado a ese archivo.

¡Y eso es todo! Si desplegamos ahora nuestro despliegue veremos las siguientes cosas:

  • Nuestra aplicación de despliegue se ha lanzado con tres contenedores en lugar de uno porque dos de ellos están relacionados con Hashicorp Vault, como puedes ver en la imagen a continuación:
Cómo inyectar secretos en pods para mejorar la seguridad con Hashicorp Vault en 5 minutos
  • vault-agent-init será el contenedor que establece la conexión con el servidor de vault porque cualquier contenedor comienza y realiza la primera descarga e inyección de secretos en el pod según la configuración proporcionada.
  • vault-agent será el contenedor que se ejecuta como un observador para detectar cualquier modificación en los secretos relacionados y actualizarlos.
Cómo inyectar secretos en pods para mejorar la seguridad con Hashicorp Vault en 5 minutos

Y ahora, si vamos al contenedor principal, veremos en la ruta /vault/secrets que el secreto ha sido finalmente inyectado como se esperaba:

Cómo inyectar secretos en pods para mejorar la seguridad con Hashicorp Vault en 5 minutos

Y así es como fácilmente y sin ningún conocimiento sobre la aplicación subyacente podemos inyectar secretos en pods usando Hashicorp Vault.

📚 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.

Configuración de TIBCO BW Hashicorp Vault: Más Potente y Mejor Protegida en 3 Pasos

Configuración de TIBCO BW Hashicorp Vault: Más Potente y Mejor Protegida en 3 Pasos

Introducción

Este artículo tiene como objetivo mostrar la Configuración de TIBCO BW Hashicorp Vault para integrar su aplicación TIBCO BW con los secretos almacenados en Hashicorp Vault, principalmente para la externalización y gestión de recursos de contraseñas y credenciales.

Como probablemente sepa, en la aplicación TIBCO BW, la configuración se almacena en Propiedades a diferentes niveles (propiedades de Módulo o Aplicación). Puede leer más sobre ellas aquí. Y el propósito principal de esas propiedades es proporcionar flexibilidad a la configuración de la aplicación.

Estas propiedades pueden ser de diferentes tipos, como String, Integer, Long, Double, Boolean y DateTime, entre otros recursos técnicos dentro de TIBCO BW, como se muestra en la imagen a continuación:

Configuración de TIBCO BW Hashicorp Vault: Tipos de Propiedades BW

La integración de TIBCO BW Hashicorp Vault afectará solo a aquellas propiedades de tipo Contraseña (al menos hasta la versión 2.7.2/6.8.1 de BW). La razón detrás de esto es que esas propiedades son el tipo de datos relevantes para la información que es sensible y necesita ser segura. Otros conceptos pueden ser gestionados a través de componentes estándar de Kubernetes como ConfigMaps.

Definición de la Aplicación BW

Vamos a comenzar con una aplicación sencilla, como puede ver en la imagen a continuación:

Configuración de TIBCO BW Hashicorp Vault: Ejemplo de Propiedad

Solo un temporizador simple que se ejecutará una vez e insertará la hora actual en la base de datos PostgreSQL. Usaremos Hashicorp Vault para almacenar la contraseña del usuario de la base de datos para poder conectarnos a ella. El nombre de usuario y la cadena de conexión residirán en un ConfigMap.

Omitiremos la parte de la configuración relacionada con el despliegue de los Contenedores de la aplicación TIBCO BW y enlazaremos a un ConfigMap. Tiene un artículo que cubre eso en detalle en caso de que necesite seguirlo, y nos centraremos solo en el tema relacionado con la integración de TIBCO BW Hashicorp Vault.

Así que necesitaremos decirle a TIBCO BW que la contraseña del Recurso Compartido JDBC estará vinculada a la configuración de Hashicorp Vault, y para hacer eso, lo primero es haber vinculado la Contraseña de los Recursos Compartidos a una Propiedad de Módulo como se muestra en la imagen a continuación:

Configuración de TIBCO BW Hashicorp Vault: Contraseña vinculada a Propiedad de Módulo

Ahora, necesitamos decirle a esta Propiedad de Módulo que está vinculada a Hashicorp Vault, y lo haremos en la Vista de Propiedades de la Aplicación, seleccionando que esta propiedad está vinculada a una Solución de Gestión de Credenciales como se muestra en la imagen a continuación:

Configuración de TIBCO BW Hashicorp Vault: Configuración de Gestión de Credenciales para Propiedad

Y es ahora cuando establecemos la relación de TIBCO BW Hashicorp Vault. Necesitamos hacer clic directamente en el signo más verde, y tendremos una ventana modal que nos pedirá la tecnología de gestión de credenciales que vamos a usar y los datos necesarios para cada una de ellas, como puede ver en la siguiente imagen:

Configuración de TIBCO BW Hashicorp Vault: Configuración de Gestión de Credenciales para Propiedad

Seleccionaremos Hashicorp Vault como el proveedor. Luego necesitaremos proporcionar tres atributos que ya comentamos en el artículo anterior cuando comenzamos a crear secretos en Hashicorp Vault:

  • Nombre del Secreto: este es el nombre del secreto después de la ruta raíz del elemento.
  • Clave del Secreto: Esta es la clave dentro del propio secreto
  • Ruta de Montaje: Esta es la ruta raíz del secreto

Para obtener más detalles sobre estos tres conceptos, por favor, consulte nuestro artículo sobre cómo crear secretos en Hashicorp Vault.

Así que con todo esto, tenemos prácticamente todo lo que necesitamos para conectarnos a Hashicorp Vault y obtener el secreto, y desde el lado de TIBCO BW BusinessStudio, todo está hecho; podemos generar el archivo EAR y desplegarlo en Kubernetes porque aquí está la última parte de nuestra configuración.

 Despliegue en Kubernetes

Hasta este momento, ya hemos proporcionado la siguiente información:

  • Proceso BW que tiene el inicio de sesión para conectarse a la Base de Datos e insertar información
  • Enlace entre la propiedad de contraseña utilizada para conectar y la definición del Secreto de Hashicorp

Así que, prácticamente todo está ahí, pero falta un concepto. ¿Cómo se conectará el Pod de Kubernetes a Hashicorp una vez que el pod esté desplegado? Hasta este punto, no proporcionamos la ubicación del servidor de Hashicorp Vault del método de autenticación para conectarse a él. Esta es la parte que falta de la integración de TIBCO BW Hashicorp Vault y será parte del archivo YAML de Despliegue de Kubernetes.

Lo haremos usando las siguientes propiedades de entorno en este ejemplo:

Configuración de TIBCO BW Hashicorp Vault: Variables de Entorno de Hashicorp
  • HASHICORP_VAULT_ADDR: Esta variable apuntará a donde se encuentra el servidor de Hashicorp Vault
  • HASHICORP_VAULT_AUTH: Esta variable indicará qué opciones de autenticación se utilizarán. En nuestro caso, usaremos la de token como usamos en el artículo anterior
  • HASHICORP_VAULT_KV_VERSION: Esta variable indica qué versión de la solución de almacenamiento KV estamos usando y será dos por defecto.
  • HASHICORP_VAULT_TOKEN: Este será solo el valor del token para poder autenticarse contra el servidor de Hashicorp Vault

Si está utilizando otros métodos de autenticación o simplemente quiere saber más sobre esas propiedades, por favor, eche un vistazo a esta documentación de TIBCO.

Con todo eso agregado a las propiedades de entorno de nuestra aplicación TIBCO BW, podemos ejecutarla, y obtendremos una salida similar a esta, que muestra que la integración de TIBCO BW Hashicorp Vault se ha realizado y la aplicación pudo iniciarse sin ningún problema

Configuración de TIBCO BW Hashicorp Vault: Ejecución de ejemplo

Crea Secretos en Hashicorp Vault Usando 2 Formas Fáciles

Crea Secretos en Hashicorp Vault Usando 2 Formas Fáciles

Introducción

Crear secretos en Hashicorp Vault es una de las cosas más importantes y relevantes que puedes hacer una vez que has instalado Hashicorp Vault en tu entorno, probablemente recuperando y obteniendo estos secretos de los componentes que los necesitan. Pero en el artículo de hoy, nos centraremos en la primera parte para que puedas aprender lo fácil que es crear secretos en Hashicorp Vault.

En artículos anteriores comentamos la importancia de Hashicorp Vault y el proceso de instalación, como puedes leer aquí. Por lo tanto, en este punto, ya tenemos nuestra bóveda lista para comenzar a trabajar con ella completamente inicializada y desbloqueada para poder comenzar a atender solicitudes.

Crear Secretos en Hashicorp Vault usando Comandos CLI de Hashicorp Vault

Todos los comandos que realizaremos usarán un componente crítico llamado Hashicorp Vault CLI, y notarás eso porque todos nuestros comandos comenzarán con vault. Para ser honesto, ya comenzamos con eso en el artículo anterior; si recuerdas, ya ejecutamos algunos de estos comandos para inicializar o desbloquear la bóveda, pero ahora este será nuestro componente principal para interactuar.

Lo primero que necesitamos hacer es poder iniciar sesión en la bóveda, y para hacer eso; vamos a usar el token raíz que se nos proporcionó cuando inicializamos la bóveda; vamos a almacenar esta bóveda en una variable de entorno para que sea fácil trabajar con ella. Todos los comandos que vamos a ejecutar ahora estarán dentro del pod del servidor del agente de la bóveda, como se muestra en la imagen a continuación:

Crear Secretos en Hashicorp Vault: Detectando Pod del Servidor de la Bóveda

Una vez que estemos dentro, vamos a hacer el comando de inicio de sesión con la siguiente sintaxis:

 vault login 

Y obtendremos una salida similar a esta:

Crear Secretos en Hashicorp Vault: Iniciando sesión en Hashicorp Vault

Si no proporcionamos el token de antemano, la consola pedirá que se escriba el token posteriormente, y se ocultará automáticamente, como puedes ver en la imagen a continuación:

Crear Secretos en Hashicorp Vault: Iniciando sesión sin Token proporcionado

Después de este punto, ya estamos conectados a la bóveda, por lo que podemos comenzar a escribir comandos para crear secretos en Hashicorp Vault. Comencemos con ese proceso.

Para comenzar con nuestro proceso de creación de secretos en Hashicorp Vault, primero necesitamos hacer o ser más precisos con la sintaxis de Hashicorp Vault para habilitar una ruta de secreto que puedes pensar como la ruta raíz a la que estarán relacionados todos tus secretos. Si estamos hablando de tener secretos para diferentes aplicaciones, cada ruta puede ser cada una de las aplicaciones, pero la organización de los secretos puede ser diferente dependiendo del contexto. Cubriremos eso con mucho más detalle en los siguientes artículos.

Para habilitar la ruta de secreto para comenzar la creación de secretos en Hashicorp Vault, escribiremos el siguiente comando:

 vault secrets enable -path=internal kv-v2

Eso habilitará un almacén de secretos del tipo kv-v2 (almacén de clave-valor en su v2), y la ruta será “internal,” por lo que todo lo que creemos después de eso estará bajo esta ruta raíz “internal.”

Y ahora, vamos a hacer la creación del secreto en Hashicorp Vault, y como estamos usando un almacén de clave-valor, la sintaxis también está relacionada con eso porque vamos a “poner” un secreto usando el siguiente comando:

 vault kv put internal/database/config username="db-readonly-username" password="db-secret-password"

Eso creará dentro de la ruta interna una ruta hija /database/config donde almacenará dos claves:

  • username que tendrá el valor db-readonly-username
  • password que tendrá el valor db-secret-password

Como puedes ver, es bastante fácil crear nuevos secretos en la Bóveda vinculados a la ruta, y si deseas recuperar su contenido, también puedes hacerlo usando el CLI de la Bóveda, pero esta vez usando el comando get como se muestra en el fragmento a continuación:

 vault kv get internal/database/config

Y la salida será similar a la que se muestra a continuación:

Crear Secretos en Hashicorp Vault: Recuperando Secretos de la Bóveda

Esto te ayudará a interactuar con el contenido de tu almacén para recuperar, agregar o actualizar lo que ya tienes allí. Una vez que tengas todo listo allí, podemos pasar al lado del cliente para configurarlo para recopilar todos estos datos como parte de su flujo de trabajo de ciclo de vida.

Crear Secretos en Hashicorp Vault usando REST API

El CLI de Hashicorp Vault simplifica la interacción con el servidor de la bóveda, pero toda la interacción entre el CLI y el servidor ocurre a través de una REST API que el servidor expone y el cliente CLI consume. Proporciona una sintaxis simplificada al usuario y traduce los parámetros proporcionados en solicitudes REST al servidor, pero también puedes usar solicitudes REST para ir directamente al servidor. Por favor, consulta este artículo en la documentación oficial para obtener más detalles sobre la REST API.

Instalación de Hashicorp Vault en Kubernetes: Rápida y Sencilla en 3 Pasos Fáciles

Instalación de Hashicorp Vault en Kubernetes: Rápida y Sencilla en 3 Pasos Fáciles

Introducción

En este artículo, vamos a cubrir la instalación de Hashicorp Vault en Kubernetes. Hashicorp Vault se ha convertido en uno de los estándares de la industria cuando hablamos de gestionar secretos y datos sensibles en entornos de producción, y esto cubre implementaciones en la nube y no nativas de la nube. Pero especialmente en Kubernetes, este es un componente crítico. Ya hemos comentado que los Secretos de Kubernetes no están muy seguros por defecto, por lo que HashiCorp Vault resuelve ese problema.

Métodos de Instalación

Hashicorp Vault proporciona muchos métodos de instalación diferentes que puedes leer en su página oficial aquí; la mayoría todavía se centra en un entorno tradicional. Pero en resumen, estos son los que tienes disponibles:

  • Instalar desde el gestor de paquetes
  • Instalar desde un binario preexistente
  • Instalar desde el código fuente
  • Helm para Kubernetes

Como puedes imaginar, el camino que seguiremos aquí es el de Helm. Supongo que ya estás familiarizado con Helm, pero si no, echa un vistazo aquí, y si también estás en el proceso de crear charts de helm, este otro también puede ayudarte.

Chart de Helm para Hashicorp Vault

Para el propósito de este artículo, vamos a lo que se llama una instalación de hashicorp vault independiente, por lo que no vamos a crear en este post una arquitectura con Alta Disponibilidad (HA) que esté lista para producción, sino algo que pueda ayudarte a comenzar a jugar con la herramienta y ver cómo esta herramienta puede integrarse con otras que pertenecen al mismo entorno nativo de la nube. Para obtener más información sobre cómo implementar Hashicorp Vault en una configuración lista para producción, consulta el siguiente enlace.

Primero necesitamos instalar el chart de helm en nuestro entorno local, pero debemos tener mucho cuidado con la versión de helm que tenemos. Al escribir este artículo, la instalación de Hashicorp Vault requiere una versión de Helm 3.7+, por lo que primero debes verificar la versión que tienes instalada.

En caso de que estés ejecutando una versión anterior, obtendrás el siguiente error:

 Error: parse error at (vault/templates/_helpers.tpl:38): unclosed action

Puedes obtener más detalles sobre este problema de GitHub.

Al momento de escribir este artículo, la última versión de Helm es 3.9, pero esta versión genera un problema con AWS EKS con este error:

 Error: Kubernetes cluster unreachable: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1alpha1."
Failed installing **** with helm

Puedes obtener más detalles sobre este problema de GitHub.

Entonces, en ese caso, la mejor manera de asegurarse de que no habrá un problema con la instalación de Hashicorp Vault es degradar a 3.8, y podrás implementar el chart de helm sin ningún problema.

Proceso de Instalación de Hashicorp Vault

Para proceder con la instalación de Hashicorp Vault, necesitamos ejecutar los siguientes comandos:

helm repo add hashicorp https://helm.releases.hashicorp.com
helm install vault hashicorp/vault

Esto instalará dos componentes diferentes: un único servidor de vault como parte de un StatefulSet y un vault-agent-injector para gestionar la inyección de la configuración de vault en los diversos componentes e implementaciones en los otros espacios de nombres.

Para que los pods se ejecuten, necesitamos inicializar y desellarlo antes de estar listos para usar. Para hacer eso, necesitamos entrar dentro del pod del servidor de vault y ejecutar los siguientes comandos:

 vault operator init

Esto generará varias cosas esenciales:

  • Generará las claves para poder desellar el vault y comenzar a usarlo. Mostrará un número diferente de claves, en nuestro ejemplo 5, y necesitarás al menos 3 de ellas para poder desellar el vault.
  • También generará un token raíz para poder iniciar sesión en la CLI e interactuar con el servidor para poder leer y escribir secretos.

Después de eso, necesitaremos ejecutar el siguiente comando al menos tres veces, proporcionando cada uno de ellos con una clave de desellado diferente:

 Vault operator unseal

Después de ese punto, todos los componentes están en ejecución y listos, y podemos concluir nuestra instalación de Hashicorp Vault y comenzar a interactuar con el vault para crear tus secretos.

Instalación de Hashicorp Vault: Todos los Componentes Listos

Descubriendo la Verdad Detrás de los Secretos de Kubernetes

man in white dress shirt wearing black framed eyeglasses
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.