External Secrets

https://external-secrets.io

En el complejo ecosistema de Kubernetes, la gestión de información sensible, como contraseñas, claves de API y tokens de autenticación, representa un desafío crítico para la seguridad y operabilidad de las aplicaciones.

El External Secrets Operator (ESO) es una solución robusta, consolidada en la CNCF, ideal para sincronizar secretos de fuentes externas directamente dentro del clúster de Kubernetes.

Es un operador de Kubernetes que extiende la API de Kubernetes con Recursos Personalizados (Custom Resource Definitions - CRDs). Su función principal es leer información de proveedores de secretos externos, como AWS Secrets Manager, HashiCorp Vault, Google Secret Manager y Azure Key Vault, e inyectarla automáticamente como Secrets nativos de Kubernetes.

En su esencia, el ESO actúa como un puente seguro. Los equipos de desarrollo y operaciones pueden mantener sus secretos centralizados y gestionados en un lugar seguro y auditable, mientras que las aplicaciones dentro de Kubernetes pueden consumir esos secretos de la manera estándar, a través de variables de entorno o volúmenes, sin la necesidad de modificaciones complejas.

La arquitectura de External Secrets se basa en dos CRDs principales:

• SecretStore o ClusterSecretStore: Define cómo conectarse y autenticarse en un proveedor de secretos externo. La versión ClusterSecretStore permite que la configuración sea accesible por todos los namespaces del clúster, mientras que SecretStore está limitado a un único namespace.

• ExternalSecret: Describe qué secreto debe buscarse en el proveedor externo y cómo debe crearse o actualizarse en Kubernetes. Este recurso hace referencia a un SecretStore para obtener las credenciales de acceso necesarias.

Ventajas

• Centralización y Gestión Externa: Permite que los secretos sean gestionados por sistemas especializados, que ofrecen recursos avanzados de auditoría, rotación automática y políticas de acceso granulares.

• Seguridad Mejorada (GitOps): Al evitar que los valores de los secretos se almacenen directamente en los manifiestos YAML de Kubernetes, External Secrets es un aliado fundamental para prácticas de GitOps. Los repositorios Git contienen solo la referencia al secreto externo, no su valor, reduciendo drásticamente el riesgo de exposición.

• Sincronización Automática: El operador monitorea continuamente el proveedor de secretos externo. Cualquier cambio en los secretos se sincroniza automáticamente con los Secrets correspondientes en Kubernetes, garantizando que las aplicaciones siempre tengan las credenciales más recientes.

• Compatibilidad con Aplicaciones: Como el resultado final es un Secret nativo de Kubernetes, las aplicaciones no necesitan ninguna lógica personalizada para interactuar con el proveedor de secretos. Consumen los secretos de la forma en que siempre lo hicieron.

• Amplio Soporte de Proveedores: La herramienta es compatible con una amplia gama de proveedores de secretos, tanto de nubes públicas como soluciones on-premises, ofreciendo flexibilidad para diferentes arquitecturas.

• Comunidad Activa y Proyecto de Código Abierto: Siendo un proyecto de la CNCF (Cloud Native Computing Foundation), External Secrets posee una comunidad vibrante y un desarrollo activo, lo que garantiza buen soporte, actualizaciones constantes y una base de usuarios sólida.

Desventajas

A pesar de sus numerosas ventajas, es importante considerar algunos puntos antes de adoptar External Secrets:

• Complejidad de Configuración Inicial: Implica la creación de SecretStores y la definición de permisos correctos tanto en el clúster como en los proveedores externos, puede ser compleja para equipos menos experimentados con Kubernetes.

• Aún Utiliza Secrets Nativos: Para aplicaciones que requieren el más alto nivel de seguridad, el hecho de que External Secrets materialice el secreto en un Secret nativo de Kubernetes (que por defecto solo está codificado en Base64 en el etcd) puede ser una desventaja. Aunque el etcd puede estar cifrado, algunas políticas de seguridad pueden prohibir el almacenamiento de secretos en el clúster. Puede considerarse una ventaja o desventaja el hecho de que el secreto se materialice como objeto en el clúster. Si fuéramos a inyectar un secreto directamente desde vault o cualquier otro proveedor durante la inicialización de un pod y esa conexión falla, el pod no se inicializaría, pero en un secret que ya está en kubernetes eliminamos una dependencia más.

• Dependencia de un Componente Adicional: Añade un controller más en el clúster que necesita ser monitoreado, mantenido y actualizado.

• Performance en Gran Escala: En clústeres muy grandes con un número masivo de secretos siendo sincronizados, el rendimiento del operador puede convertirse en un punto de atención, consumiendo recursos y generando un volumen considerable de logs.

• Tiempo de Sync: Existe una latencia entre que el external secret entiende que un secreto cambió.

¿Por qué se Convirtió en la Herramienta Más Utilizada?

El ascenso de External Secrets al puesto de herramienta más utilizada para la gestión de secretos en Kubernetes puede atribuirse a una combinación de factores:

• Solución para un Problema Universal: La gestión de secretos es un dolor universal en ambientes de contenedores, y External Secrets ofrece una solución elegante y efectiva que se integra perfectamente al ecosistema de Kubernetes.

• Enfoque "GitOps-Friendly": Con la popularización de GitOps como estándar para la entrega continua, la capacidad de mantener los secretos fuera de los repositorios Git se convirtió en un requisito fundamental.

• Equilibrio entre Seguridad y Usabilidad: La herramienta encuentra un excelente equilibrio al permitir que los secretos sean gestionados en cofres externos seguros, sin imponer una gran sobrecarga de desarrollo a los equipos de aplicación, que pueden continuar consumiendo los secretos de manera familiar.

External Secrets vs. Sealed Secrets Vs. GitOps

Mientras que el External Secrets Operator (ESO) se consolidó como una de las soluciones más populares y robustas, Sealed Secrets ofrece un enfoque distinto y más simple, que puede ser ideal para determinados escenarios. La elección entre ellos depende fundamentalmente de la arquitectura, la escala de su operación y su flujo de trabajo de GitOps.

External Secrets: Su principal ventaja reside en la centralización y gestión unificada de los secretos, actuando como un HUB que facilita la auditoría, rotación de claves, etc., pero que trae consigo las dependencias de servicios externos y una complejidad extra como ya vimos antes.

Sealed Secrets: Tiene un enfoque completo en GitOps, pero viene con un enfoque completamente diferente. En lugar de conectarse a un cofre externo, permite cifrar secretos de forma segura para que puedan almacenarse directamente en un repositorio Git.

Cómo Funciona Sealed Secrets

Un controlador se instala en el clúster de Kubernetes, que genera un par de claves (pública y privada).

La clave pública se utiliza para cifrar (sellar) sus archivos de manifiesto de Secret de Kubernetes. El resultado es un nuevo objeto SealedSecret, que es seguro para ser commiteado en Git.

El controlador en el clúster es el único que posee la clave privada y, por lo tanto, el único capaz de descifrar (revelar) el SealedSecret y crear el Secret nativo en el clúster.

Principales Ventajas de Sealed Secrets

• Flujo de Trabajo de GitOps Puro: Permite que todo, incluyendo los secretos, sea versionado y gestionado a través de Git. Esto simplifica el proceso de implantación y garantiza un estado declarativo completo de su infraestructura.

• Autocontenido: No hay dependencias de servicios externos para la gestión de los secretos en tiempo de ejecución. Todo lo necesario está en el clúster y en el repositorio Git.

• Simplicidad: Es relativamente más simple de configurar y usar en comparación con External Secrets, especialmente para equipos pequeños y ambientes menos complejos.

• Seguridad en el Repositorio: El secreto original nunca se expone en el repositorio Git, solo su versión cifrada.

Desventajas de Sealed Secrets

• Gestión Descentralizada: Cada clúster posee su propio par de claves, lo que puede dificultar la gestión de secretos en varios clústeres.

• Rotación de Claves: La rotación de la clave de cifrado de Sealed Secrets requiere el recifrado de todos los secretos existentes, lo que puede ser un proceso manual y propenso a errores.

• Menos Recursos Avanzados: No ofrece los mismos recursos de auditoría y gestión del ciclo de vida de secretos que los proveedores de secretos dedicados.

Es importante recordar que las limitaciones pueden ser solventadas y los procesos manuales automatizados, pero no es una funcionalidad que ya viene con la herramienta.

Característica	External Secrets Operator	Sealed Secrets
Fuente de la Verdad	Proveedor de secretos externo (Vault, AWS SM, etc.)	Repositorio Git
Flujo de Trabajo	Sincronización con fuente externa	Cifrado y commit en Git (GitOps)
Dependencias	Proveedor de secretos externo	Autocontenido en el clúster
Escalabilidad	Alta, ideal para múltiples clústeres	Menos escalable para múltiples clústeres
Rotación de Secretos	Gestionada por el proveedor externo, sincronización automática	Manual, requiere recifrado
Complejidad	Moderada a alta	Baja a moderada
Caso de Uso Ideal	Ambientes corporativos, múltiples clústeres, necesidad de auditoría centralizada.	Proyectos que siguen GitOps estrictamente, ambientes más simples, almacenamiento de toda la configuración en Git.

---

Para la mayoría de las organizaciones que ya utilizan un proveedor de secretos centralizado o que operan en una escala que exige gestión y auditoría robustas, External Secrets es, de hecho, la opción más completa y segura.

Sin embargo, Sealed Secrets tiene un valor inmenso y no debe ser descartado. Es una excelente opción para:

• Equipos que adoptan GitOps como filosofía principal y desean tener una única fuente de verdad declarativa en sus repositorios.

• Escenarios más simples, con un número limitado de clústeres, donde la sobrecarga de gestionar un cofre de secretos externo no se justifica.

• Aplicaciones de código abierto o proyectos donde la simplicidad y la ausencia de dependencias externas son prioritarias.