Marcio Cunha

Cómo gestionar secretos en Kubernetes con Vault

Aprende a aplicar estándares modernos de seguridad para inyección dinámica de credenciales y rotación automática en clústeres de Kubernetes usando External Secrets y Vault.

Marcio Cunha•4 min
También disponible en:PortuguêsEnglish
Resumen
  • Kubernetes almacena secretos de forma nativa codificados en Base64 en lugar de estar fuertemente cifrados en reposo en etcd.
  • HashiCorp Vault actúa como una bóveda centralizada de credenciales que soporta motores dinámicos y políticas estrictas de acceso.
  • El External Secrets Operator sincroniza automáticamente los datos de Vault hacia los objetos Secret nativos de Kubernetes.
  • La inyección dinámica elimina la necesidad de credenciales estáticas escritas directamente en el código fuente.
  • La rotación automática de secretos en tiempo de ejecución reduce drásticamente la ventana de vulnerabilidad ante brechas.

Por qué gestionar secretos en Kubernetes es un gran desafío

Al ejecutar aplicaciones en contenedores, los equipos se enfrentan rápidamente a la necesidad de alimentar microservicios con datos sensibles como contraseñas de bases de datos, claves de API y certificados SSL. En el universo de Kubernetes, la herramienta nativa para esto es el objeto Secret. Sin embargo, en la práctica, esta función predeterminada solo codifica la información usando Base64, que cualquier persona puede revertir fácilmente. Además, las credenciales se almacenan de forma estática en la base de datos interna del clúster llamada etcd, sin mecanismos eficientes de rotación automatizada. Cuando un desarrollador deja el equipo o cambian las estructuras, modificar estas claves sin romper el sistema se convierte en una pesadilla.

Para resolver este cuello de botella de seguridad en producción, debemos abandonar el almacenamiento estático y adoptar una estrategia basada en bóvedas externas dedicadas y la inyección en tiempo real. Tal como exploramos en nuestra guía completa sobre gestión de secretos con Vault, centralizar el control de acceso garantiza que las aplicaciones reciban credenciales efímeras que expiran por sí solas. En lugar de esparcir contraseñas por archivos YAML perdidos en el repositorio, delegamos la custodia y auditoría a herramientas especializadas, manteniendo el clúster aislado de riesgos innecesarios.

El papel de HashiCorp Vault en la protección de credenciales

HashiCorp Vault es un software diseñado específicamente para gestionar secretos y restringir el acceso a datos confidenciales. En la práctica, funciona como una caja fuerte digital altamente fortificada que exige una autenticación rigurosa antes de liberar información. Una de sus mayores ventajas es la capacidad de generar credenciales dinámicas bajo demanda. Por ejemplo, cuando un microservicio necesita consultar una base de datos, Vault crea una cuenta temporal con permisos mínimos, establece un tiempo de expiración corto y revoca la cuenta automáticamente al terminar. Esto mitiga enormemente los daños si un atacante intercepta el tráfico.

Integrar ecosistemas de microservicios con sistemas externos también exige un monitoreo riguroso para evitar cuellos de botella operativos y fallos silenciosos. Tal como discutimos en nuestra guía práctica de depuración con OpenTelemetry, monitorear el comportamiento de las aplicaciones y rastrear dependencias ayuda a identificar rápidamente si un fallo de autenticación está afectando los servicios. Con Vault, cada petición de secreto genera un registro de auditoría detallado, permitiendo al equipo de seguridad saber exactamente quién accedió y cuándo.

Cómo funciona el External Secrets Operator en la práctica

Aunque Vault es excelente guardando secretos, las aplicaciones en Kubernetes siguen esperando encontrar objetos Secret nativos dentro de sus namespaces. Aquí es donde entra el External Secrets Operator, un controlador inteligente que corre en el clúster monitoreando cambios y sincronizando datos. En la práctica, lee instrucciones de un recurso personalizado llamado ExternalSecret, busca la credencial actualizada en Vault y crea o actualiza el Secret de Kubernetes de forma transparente y automatizada para los desarrolladores.

El gran beneficio arquitectónico de este enfoque es que los desarrolladores continúan usando el modelo estándar de Kubernetes que ya conocen, mientras la infraestructura de seguridad gestiona el ciclo de vida de las claves tras bambalinas. El operador se ejecuta en segundo plano verificando actualizaciones de contraseñas y refresca el objeto interno sin requerir reinicios manuales de pods. Esto garantiza transiciones fluidas sin cortes de conexión, manteniendo compatibilidad con aplicaciones heredadas que dependen de variables de entorno.

Implementando la sincronización automática de secretos

Para establecer esta arquitectura en un clúster de producción, los componentes deben configurarse en orden correcto, asegurando que la comunicación entre el operador y la bóveda utilice tokens seguros o identidades basadas en la nube. El procedimiento involucra crear un secreto inicial de autenticación, definir un objeto que apunte a la dirección de Vault y mapear las claves hacia Kubernetes. A continuación, mostramos la estructura básica de configuración.

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: secreto-base-datos
  namespace: produccion
spec:
  refreshInterval: "1h"
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: app-db-secret
    creationPolicy: Owner
  data:
  - secretKey: password
    remoteRef:
    key: secret/data/produccion/db
    property: password

Una vez aplicado este manifiesto, el operador consulta Vault cada hora para verificar cambios en la contraseña. Si existe una nueva versión en la bóveda, el objeto interno llamado app-db-secret se actualiza de inmediato. Esta automatización elimina scripts manuales de actualización y reduce a casi cero el riesgo de olvidos en la rotación periódica de credenciales corporativas.

Asegurar la resiliencia durante la rotación automática de claves es fundamental para evitar caídas de servicio. Cuando Vault cambia una contraseña en la base de datos relacional, debe mantener la clave anterior activa durante un breve periodo de gracia de unos minutos, permitiendo que los pods antiguos sigan operando mientras procesan el cambio. Asimismo, el operador almacena una caché local, garantizando que si Vault sufre una interrupción temporal, las aplicaciones sigan funcionando sin inconvenientes.

Consideraciones finales sobre seguridad y gobernanza

Gestionar secretos en Kubernetes va mucho más allá de ocultar contraseñas en archivos de configuración; implica establecer un ciclo de vida completo que abarca creación, inyección dinámica, auditoría y rotación automática. La combinación de HashiCorp Vault con el External Secrets Operator ofrece un estándar de mercado maduro capaz de cumplir con requisitos normativos estrictos sin ralentizar el flujo de trabajo de los desarrolladores. Al eliminar credenciales estáticas, tu organización blinda los entornos de producción contra fugas accidentales y gana visibilidad total sobre los datos sensibles.