Cada clúster de Kubernetes viene con un objeto “secreto” incorporado. Parece seguridad. Se siente como seguridad. No es seguridad.
Un secreto de Kubernetes es, de forma predeterminada, solo una cadena codificada en base64 almacenada en etcd, legible por cualquier persona con acceso al clúster y trivialmente decodificable con una sola línea: echo "c2VjcmV0" | base64 -d. A menos que haya habilitado explícitamente el cifrado en reposo (y la mayoría de los equipos no lo han hecho), las contraseñas de su base de datos, los tokens API y las claves privadas TLS se encuentran sin cifrar en el almacén de datos del plano de control de su clúster. Confirme un manifiesto de Kubernetes que contenga un “Secreto” en Git y esa credencial permanecerá en el historial de su repositorio para siempre.
Este es el problema para el que ha surgido una nueva generación de herramientas de gestión de secretos, y en 2026, el ecosistema ha madurado significativamente. Esta guía cubre las seis herramientas más importantes para administrar secretos en entornos de Kubernetes: qué hacen, qué no hacen y cuál se adapta al nivel de madurez de su equipo.
Lectura relacionada: Si le preocupa que se filtren secretos a través de su canalización de CI/CD, consulte nuestro resumen de las mejores herramientas de canalización de CI/CD. Para obtener un panorama más amplio de la seguridad de los contenedores, consulte nuestra guía de herramientas de escaneo de vulnerabilidades.
Por qué los secretos predeterminados de Kubernetes se quedan cortos
Antes de profundizar en las herramientas, vale la pena ser preciso acerca de lo que le falta a Kubernetes Secrets, porque comprender la brecha es lo que le permite elegir la solución adecuada.
No hay cifrado en reposo de forma predeterminada. etcd almacena los secretos de Kubernetes como base64, no cifrados. Habilitar Cifrado en reposo es un paso de configuración a nivel de clúster que los proveedores de Kubernetes administrados (EKS, GKE, AKE) manejan de manera diferente, y muchos clústeres autoadministrados lo omiten por completo.
Sin rotación de secretos. No existe ningún mecanismo integrado para que un secreto de Kubernetes sepa que su credencial de respaldo ha cambiado. Usted rota una contraseña de base de datos externamente y sus pods siguen usando la anterior hasta que actualiza manualmente el secreto y reinicia los pods afectados.
No hay registro de auditoría para el acceso secreto. El registro de auditoría estándar de Kubernetes registra las modificaciones de objetos secretos, pero la mayoría de las configuraciones no registran lecturas individuales, lo que significa que no puedes responder “¿qué servicio accedió a este token y cuándo?”.
Git-hostil por diseño. El consejo estándar es “nunca envíe secretos a Git”. Pero en un mundo GitOps donde el objetivo es todo como código, esa es una excepción dolorosa de mantener.
RBAC como instrumento contundente. Kubernetes RBAC le permite otorgar o denegar acceso a objetos secretos a nivel de espacio de nombres. No puede expresar “El servicio A puede leer el secreto X pero no el secreto Y” o “este secreto vence en 24 horas”.
Ninguna de estas son razones para abandonar Kubernetes; son razones para utilizar además herramientas de gestión de secretos dedicadas.
TL;DR — Comparación de funciones
| Herramienta | Cifrado en reposo | Secretos dinámicos | Registros de auditoría | K8 nativo | Nube múltiple | Precios |
|---|---|---|---|---|---|---|
| Bóveda de HashiCorp | ✅ | ✅ | ✅ | ⚠️ (a través del agente) | ✅ | OSS gratuito / HCP pagado |
| Operador de secretos externos | ✅ (a través del backend) | ✅ (a través del backend) | ✅ (a través del backend) | ✅ | ✅ | Gratis / OSS |
| Secretos sellados | ✅ | ❌ | ❌ | ✅ | ❌ | Gratis / OSS |
| Administrador de secretos de AWS | ✅ | ✅ | ✅ | ⚠️ (vía ESO/CSI) | ❌ (solo AWS) | Precios por secreto |
| Doppler | ✅ | ❌ | ✅ | ✅ (operador) | ✅ | Gratis → niveles pagados |
| Infisical | ✅ | ✅ | ✅ | ✅ (operador) | ✅ | OSS / nube paga |
⚠️ = requiere componentes adicionales
1. HashiCorp Vault: el estándar de oro para los secretos empresariales
HashiCorp Vault es el punto de referencia con el que se miden todas las demás herramientas de gestión de secretos. Ha sido probado en entornos empresariales durante casi una década y su conjunto de funciones refleja esa profundidad.
La capacidad principal de Vault son los secretos dinámicos: credenciales que se generan bajo demanda y caducan automáticamente. En lugar de almacenar una contraseña estática de PostgreSQL, Vault genera un par de nombre de usuario/contraseña único para cada servicio solicitante, válido por un período de arrendamiento configurable (por ejemplo, una hora). Cuando el contrato de arrendamiento expira, la credencial se revoca. Esto elimina clases enteras de dispersión de credenciales y facilita enormemente la contención de infracciones.
Para Kubernetes, el Vault Agent Injector o el Vault Secrets Operador son las rutas de integración. El inyector se ejecuta como un webhook mutante que incorpora automáticamente un agente de Vault a sus pods, que se autentica en Vault utilizando la cuenta de servicio Kubernetes del pod y escribe secretos en un volumen compartido en memoria. El Operador de secretos de Vault (VSO), el enfoque más nuevo, sincroniza los secretos de Vault con objetos secretos nativos de Kubernetes, lo que es más familiar para los operadores, a costa de los secretos que existen brevemente en etcd.
Los motores secretos de Vault cubren una gama impresionante:
- Credenciales de bases de datos (PostgreSQL, MySQL, MongoDB y más)
- Credenciales dinámicas de AWS, GCP y Azure
- Generación de certificados PKI y TLS
- Firma de certificado SSH
- Tokens de cuenta de servicio de Kubernetes
Lo que Vault hace bien: Credenciales dinámicas, políticas de acceso detalladas, un registro de auditoría integral y un ecosistema de complementos maduro. Si necesita una gestión de secretos de grado de cumplimiento con un seguimiento completo de quién accedió a qué cuándo, Vault suele ser la única opción razonable.
A qué prestar atención: Vault tiene una complejidad operativa. Ejecutarlo en modo de alta disponibilidad requiere atención cuidadosa a los backends de almacenamiento (Raft es ahora la opción recomendada), los procedimientos de desprecintado y las rutas de actualización. La curva de aprendizaje es real. Presupuesto de tiempo de ingeniería de plataforma.
Precios: La versión de código abierto es gratuita y cubre la mayoría de las necesidades. HashiCorp Cloud Platform (HCP) Vault es la oferta administrada con precios basados en el horario del clúster y las operaciones secretas. El cambio de licencia BSL de 2023 condujo a la bifurcación OpenTofu para Terraform, pero el equivalente de la bifurcación de Vault (OpenBao) aún está madurando.
📚 Lectura recomendada: Hacking Kubernetes de Andrew Martin y Michael Hausenblas: excelente cobertura de las superficies de ataque de Kubernetes, incluidos escenarios secretos de exfiltración.
2. Operador de secretos externos (ESO): la capa de integración nativa de K8s
Operador de secretos externos adopta una postura arquitectónica fundamentalmente diferente: en lugar de ser una tienda de secretos en sí misma, es un puente entre Kubernetes y cualquier tienda externa que ya tenga. ESO sincroniza secretos de AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, 1Password, Doppler y una lista cada vez mayor de otros backends en objetos secretos nativos de Kubernetes.
La abstracción principal es el recurso personalizado ExternalSecret:
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: database-credentials
spec:
refreshInterval: 1h
secretStoreRef:
name: aws-secrets-manager
kind: ClusterSecretStore
target:
name: db-creds
data:
- secretKey: password
remoteRef:
key: production/db/password
ESO observa este recurso, obtiene el secreto de AWS Secrets Manager (o donde sea) y crea un secreto de Kubernetes estándar. Su aplicación lee “db-creds” como cualquier otro secreto de Kubernetes: no se requieren cambios de código. Cuando refreshInterval marca, ESO vuelve a buscar y actualiza el secreto automáticamente.
Por qué ESO será tan popular en 2026: Combina bien con las inversiones existentes. Su organización ya tiene AWS Secrets Manager (o Vault, o GCP Secret Manager). ESO simplemente hace que esos secretos sean consumibles en Kubernetes sin cambiar el código de su aplicación o sus flujos de trabajo de rotación de secretos existentes.
¿ESO o Vault Secrets Operador? Si está ejecutando Vault, VSO tiene una integración más estrecha específica de Vault (secretos dinámicos de Vault, Vault PKI). Si está en el almacén secreto nativo de un proveedor de nube, ESO es la opción más limpia. Muchos equipos ejecutan ambos: ESO para secretos estáticos almacenados en la nube y VSO para credenciales dinámicas administradas por Vault.
Precio: ESO es gratuito y de código abierto (Apache 2.0), mantenido por un proyecto sandbox de CNCF con un fuerte respaldo de la comunidad.
3. Secretos sellados: secretos cifrados compatibles con GitOps
Sealed Secrets de Bitnami resuelve un problema específico: ¿cómo se almacenan los manifiestos secretos de Kubernetes en Git sin almacenar el texto sin formato real? La respuesta es el cifrado asimétrico.
El controlador Sealed Secrets se ejecuta en su clúster y contiene una clave privada. La CLI kubeseal cifra un manifiesto secreto de Kubernetes con la clave pública del clúster, generando un CRD SealedSecret. Este manifiesto cifrado se puede enviar a Git de forma segura: solo la clave privada del clúster puede descifrarlo y solo se puede descifrar en ese clúster específico (de forma predeterminada, el texto cifrado está vinculado al espacio de nombres + nombre).
# Encrypt a secret for Git storage
kubectl create secret generic db-creds \
--from-literal=password=s3cr3t \
--dry-run=client -o yaml | \
kubeseal --format=yaml > db-creds-sealed.yaml
# This file is safe to commit
git add db-creds-sealed.yaml
Cuando aplica SealedSecret al clúster, el controlador lo descifra y crea el objeto Secret correspondiente.
Lo que Sealed Secrets hace bien: Flujos de trabajo de GitOps. Si está utilizando Argo CD o Flux y desea que todos los recursos del clúster (incluidos los secretos) se almacenen de forma declarativa en Git, Sealed Secrets se ajusta perfectamente a ese modelo. No requiere dependencias externas más allá del controlador del clúster.
Lo que no hace: Rotación, credenciales dinámicas o registro de auditoría más allá de los eventos estándar de Kubernetes. Sealed Secrets es una solución de almacenamiento Git, no una plataforma completa de gestión de secretos. Si su contraseña cambia, vuelve a cifrarla y confirmarla nuevamente.
La copia de seguridad de la clave privada es fundamental. Si pierde la clave privada del controlador, perderá la capacidad de descifrar sus secretos sellados. Haga una copia de seguridad del secreto “clave-secretos-sellados” en una ubicación separada y segura.
Precios: Totalmente gratuito y de código abierto (Apache 2.0).
4. Administrador de secretos de AWS con Kubernetes
Si sus cargas de trabajo se ejecutan principalmente en EKS (o se conectan en gran medida a los servicios de AWS), AWS Secrets Manager combinado con el Secrets Store CSI Driver o el operador de secretos externo es una opción natural. Usted guarda los secretos en el almacén administrado, cifrado y registrado por auditoría de AWS y los introduce en Kubernetes cuando es necesario.
El Controlador CSI del almacén de secretos (SSCSID) es el enfoque mantenido por CNCF: los secretos se montan directamente en pods como archivos a través de un volumen CSI, nunca se escriben en etcd como objetos secretos de Kubernetes. Esta es la ruta de mayor seguridad: los secretos existen en la memoria del pod, pero no en el almacén de secretos de Kubernetes.
volumes:
- name: secrets-store
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: aws-secrets
Las capacidades nativas de AWS Secrets Manager incluyen rotación automática de servicios compatibles (RDS, Redshift, DocumentDB y mediante Lambda para rotación personalizada), acceso entre cuentas y una profunda integración de CloudTrail para seguimientos de auditoría de cumplimiento.
Consideración de costos: AWS Secrets Manager cobra por secreto por mes y por llamada API. Para flotas grandes con muchos pequeños secretos, los costos pueden acumularse. Consulte nuestra guía de optimización de costos de la nube para conocer estrategias sobre cómo administrar el gasto de AWS relacionado con secretos.
Mejor para: Los equipos nativos de EKS que ya han invertido en el ecosistema de AWS y desean una estrecha integración de IAM y rotación de credenciales de RDS nativas.
5. Doppler: plataforma secreta SaaS para desarrolladores
Doppler adopta un enfoque basado en SaaS que prioriza la experiencia del desarrollador sobre la complejidad operativa. Usted define secretos en la interfaz de usuario de Doppler (o mediante CLI/API), los organiza por entorno (desarrollo, preparación, producción) y el operador de Doppler Kubernetes los sincroniza automáticamente con Kubernetes Secrets.
El operador sondea a Doppler en busca de cambios y actualiza el secreto de Kubernetes correspondiente, lo que opcionalmente activa el reinicio del pod cuando cambian los secretos. La configuración es una instalación única del gráfico Helm:
helm repo add doppler https://helm.doppler.com
helm install --generate-name doppler/doppler-kubernetes-operator
Donde brilla Doppler: Desarrollo local e integración de CI/CD junto con Kubernetes. La CLI de Doppler reemplaza los archivos de entorno por completo (“doppler run - your-command”), brindando los mismos secretos en los entornos locales, de CI y de producción. Para canalizaciones de CI/CD, las integraciones nativas de Doppler con GitHub Actions, CircleCI y otros eliminan la necesidad de copiar secretos en variables de entorno de canalizaciones.
Lo que Doppler no cubre: Credenciales de base de datos dinámica. Doppler es un almacén de secretos estático con historial de versiones y registro de auditoría; no es un motor de generación de secretos como Vault.
Precios: Doppler ofrece un nivel gratuito para equipos pequeños. Los planes pagos agregan SSO, solicitudes de acceso y funciones de cumplimiento. Consulte la página de precios de Doppler para conocer los niveles actuales (cambios de precios; verifique antes de presupuestar).
6. Infisical: alternativa de bóveda de código abierto
Infisical es el rival de código abierto más fuerte del duopolio Vault/Doppler. Proporciona una interfaz de usuario web, CLI, SDK y un operador de Kubernetes, que se puede implementar de forma autohospedada o consumirse como un servicio en la nube.
Infisical agregó soporte para secretos dinámicos en 2024, dirigido a la generación de credenciales de base de datos similar al motor de secretos de base de datos de Vault. El operador de Infisical Kubernetes sincroniza los CRD “InfisicalSecret” con los secretos nativos de Kubernetes, con intervalos de actualización configurables.
Para los equipos que desean una experiencia de usuario de nivel SaaS (panel de control web, flujos de trabajo de solicitud de acceso, registros de auditoría) pero no pueden usar SaaS externo debido a requisitos de cumplimiento, el autohospedado de Infisical es atractivo. Es significativamente más fácil de operar que Vault y tiene una experiencia de incorporación más amigable para los desarrolladores.
Precios: El núcleo de código abierto es gratuito. La versión alojada en la nube tiene un nivel gratuito y planes pagos para funciones avanzadas. La licencia empresarial autohospedada está disponible para entornos con mucho cumplimiento.
📚 Para profundizar en la arquitectura de seguridad de Kubernetes: Kubernetes Security and Observability en Amazon cubre secretos, RBAC, política de red y seguridad en tiempo de ejecución en un marco coherente.
Consejos de implementación
Comience con el cifrado en reposo. Antes de agregar herramientas adicionales, habilite el cifrado en reposo de Kubernetes, etc. Para los clústeres administrados, esto suele ser una única casilla de verificación. Para clústeres autoadministrados, siga la guía oficial. Esto eleva inmediatamente su postura de seguridad básica.
Adopte RBAC con privilegios mínimos para secretos. Audite qué cuentas de servicio tienen permisos de “obtener”, “listar” o “ver” sobre objetos secretos. Las cuentas de servicio predeterminadas en muchos gráficos de Helm están sobreaprovisionadas. Apriete el RBAC antes de rotar a un almacén externo.
Planifique sus convenciones de nomenclatura secretas con anticipación. Los secretos proliferan rápidamente. Una jerarquía coherente ({env}/{service}/{credential-type}) simplifica enormemente la automatización, las políticas RBAC y los flujos de trabajo de rotación en todas las herramientas.
No te saltes las pruebas de rotación secretas. Cualquiera que sea la herramienta que elijas, ejecuta un ejercicio de rotación antes de que la necesites. Verifique que su aplicación obtenga nuevas credenciales sin tiempo de inactividad. Los secretos dinámicos con Vault o ESO hacen que esto sea mucho más fácil que los secretos estáticos actualizados manualmente.
Supervise la expansión de los secretos. A medida que su plataforma crece, los secretos se acumulan. Integre informes de gestión de secretos en los paneles de ingeniería de su plataforma. Consulte nuestra guía de herramientas de monitoreo de Kubernetes para obtener herramientas de observabilidad que puedan rastrear patrones de acceso secretos.
¿Qué herramienta para qué equipo?
Equipo pequeño, nativo de la nube (AWS/GCP/Azure): Comience con el operador de secretos externo conectándose al almacén secreto nativo de su proveedor de nube. Gastos generales operativos mínimos, sólida integración de auditoría, gratis.
Primer equipo de GitOps (Argo CD/Flux): Secretos sellados para la configuración almacenada en GitOps, combinados con ESO para credenciales de tiempo de ejecución confidenciales que ni siquiera deberían estar cifradas en Git.
Empresa con requisitos de cumplimiento (SOC 2, PCI, HIPAA): HashiCorp Vault: ya sea en clúster Raft autohospedado o administrado por HCP Vault. El registro de auditoría, las credenciales dinámicas y el motor de políticas detallado son difíciles de replicar en otros lugares.
Entorno mixto centrado en la experiencia del desarrollador (K8 + local + CI/CD): Doppler para DX unificado en todos los entornos, o Infisical autohospedado si la residencia de los datos es importante.
Gran equipo de plataforma que administra entornos de múltiples clústeres: Operador de secretos externos como capa de abstracción del lado K8, respaldado por Vault o una tienda nativa de la nube. Centralizar la fuente de la verdad en una tienda mientras se utiliza ESO como adaptador universal en todos los clústeres es un patrón bien probado en 2026.
Relacionado: Para conocer los riesgos de seguridad introducidos por las herramientas de codificación de IA en sus manifiestos de Kubernetes y canalizaciones de CI/CD, consulte nuestra guía sobre riesgos de seguridad de codificación de Vibe en 2026.
Preguntas frecuentes
¿Los secretos de Kubernetes están cifrados de forma predeterminada?
No. Los secretos de Kubernetes están codificados en base64 de forma predeterminada: codificación, no cifrado. Los datos se almacenan en etcd sin cifrado a menos que habilite explícitamente el cifrado en reposo. Verifique siempre la configuración de su clúster y considere herramientas de administración de secretos externos para cargas de trabajo de producción.
¿Cuál es la diferencia entre el operador de secretos sellados y el operador de secretos externos?
Sealed Secrets cifra los manifiestos secretos para un almacenamiento Git seguro: es una solución GitOps. El operador de secretos externos obtiene secretos activos de almacenes externos (Vault, AWS Secrets Manager, etc.) y crea secretos nativos de Kubernetes a partir de ellos. Resuelven diferentes problemas y, a menudo, se utilizan juntos.
¿Qué son los secretos dinámicos y por qué son importantes?
Los secretos dinámicos son credenciales generadas bajo demanda con caducidad automática, en lugar de contraseñas estáticas almacenadas indefinidamente. HashiCorp Vault es la fuente principal de secretos dinámicos para Kubernetes. Si una credencial dinámica se ve comprometida, caduca según su propio cronograma. Esto limita drásticamente el radio de explosión en comparación con los secretos estáticos de larga duración.
¿Debería utilizar Doppler o HashiCorp Vault para Kubernetes?
Doppler gana en experiencia de desarrollador y rápida adopción. Vault gana en cumplimiento empresarial: credenciales dinámicas, registros de auditoría granulares y políticas detalladas. Para equipos pequeños y medianos, Doppler suele ser el camino más rápido. Para entornos SOC 2, PCI DSS o HIPAA, Vault suele ser la opción más defendible.
¿Cómo evito que se filtren secretos en los registros del contenedor?
Monte secretos como archivos en lugar de variables de entorno (las variables de entorno se pueden exponer a través de /proc y puntos finales de depuración). Utilice el controlador CSI de Secrets Store para omitir etcd por completo. Busque confirmaciones secretas accidentales en su canal de CI/CD con herramientas como el escáner secreto de Trivy; consulte nuestra guía de herramientas de escaneo de vulnerabilidades para obtener detalles de configuración.
¿Cuál es la mejor herramienta de gestión de secretos para un pequeño equipo de Kubernetes?
Comience con el Operador de secretos externos respaldado por el almacén de secretos nativo de su proveedor de nube. Gastos operativos mínimos, registro de auditoría sólido, gratis. Agregue el nivel gratuito de Doppler si también desea una experiencia unificada de secretos de desarrollo, CI y producción.
¿Cómo integro AWS Secrets Manager con Kubernetes?
Utilice el operador de secretos externos con un ClusterSecretStore que apunte a AWS Secrets Manager. En EKS, utilice IRSA (roles de IAM para cuentas de servicio) para la autenticación de IAM a nivel de pod; no se necesitan credenciales estáticas. En clústeres que no sean EKS, utilice un usuario de IAM con secretsmanager:GetSecretValue con alcance para sus ARN secretos específicos.