Secretos de Kubernetes: ¿Secretos Externos o Secretos Sellados?
Los Kubernetes Secrets solo están codificados en Base64, pero no están cifrados.
Un Secret de Kubernetes almacena valores sensibles en su estado de entrega únicamente como texto codificado en Base64. Quien conozca los valores puede leerlos en texto plano en cuestión de segundos. El verdadero peligro surge cuando estos Secrets acaban en el repositorio Git, donde permanecen para siempre en el historial. Dos métodos consolidados permiten sacar los secretos del texto plano sin renunciar al flujo de trabajo GitOps. La decisión depende de dónde deba residir la fuente de la verdad.
Lo más importante en resumen
- Base64 no es cifrado: Los Secrets de Kubernetes se almacenan por defecto solo codificados en etcd. Quien tenga acceso a etcd o a la API puede leerlos en texto plano. La protección real solo llega mediante el cifrado en reposo y permisos de API bien definidos.
- El texto plano en Git es el error costoso: Un secreto que se ha confirmado una vez permanece en el historial. Solo en 2025, GitGuardian encontró 28,65 millones de Secrets codificados en repositorios públicos, un tercio más que el año anterior.
- La fuente de la verdad decide: External Secrets recupera los secretos de un almacén externo; Sealed Secrets los cifra para Git. La elección depende de qué sistema gestione el Secret.
Relacionado:Cloud-native madura con Kubernetes 1.34 / OpenTofu vs. Terraform
Por qué un Secret de Kubernetes no guarda ningún secreto
¿Qué es un Secret de Kubernetes? Un Secret de Kubernetes es un objeto que separa los datos sensibles, como contraseñas, tokens o claves, de la configuración de la aplicación. Los valores se almacenan por defecto codificados en Base64 en el almacén central etcd. Base64 es una codificación, no un cifrado, por lo que cualquier persona con acceso a etcd o a la API puede leer el Secret en texto plano.
Ahí es exactamente donde comienza el riesgo operativo. Muchos equipos tratan el objeto Secret como protegido porque el valor no parece legible a simple vista. En realidad, la codificación no es más que una forma de transporte. Sin medidas adicionales, el secreto queda expuesto: en etcd, en cada objeto de respuesta de la API y en cualquier copia de seguridad del clúster que registre el estado.
La primera línea de defensa es, por tanto, el cifrado del propio etcd, combinado con permisos de acceso estrictos sobre la API. Esto protege el Secret en reposo. Sin embargo, no resuelve el segundo problema, de mayor alcance: el camino del secreto hacia la configuración. Ahí es donde se produce el verdadero error operativo.
Cuando el texto plano llega a Git
GitOps traslada la configuración deliberadamente al repositorio. Incluir el secreto en el commit es el error en sí. Un secreto confirmado una vez permanece en el historial, aunque el siguiente cambio lo elimine. Quien rota la clave no ha eliminado el secreto antiguo, sino que simplemente ha añadido uno segundo.
Esta cifra pública subestima el riesgo interno. Los repositorios internos contienen, según los mismos análisis, aproximadamente seis veces más secretos codificados de forma fija que los públicos, porque la sensación de aislamiento reduce el rigor. El riesgo no desaparece con el tiempo: una parte considerable de los secretos filtrados hace años y aún vigentes sigue siendo utilizable hoy. Un secreto en el historial de Git es un riesgo abierto mientras siga siendo válido.
Dos soluciones: External Secrets y Sealed Secrets
Ambos enfoques resuelven el mismo problema, pero intervienen en puntos distintos del flujo de trabajo. El External Secrets Operator mantiene el secreto fuera del clúster y lo recupera cuando es necesario. Sealed Secrets cifra el secreto de modo que no quede texto plano en el repositorio. Lo decisivo es qué sistema debe gestionar el secreto.
| Criterio | External Secrets Operator | Sealed Secrets |
|---|---|---|
| Fuente de verdad | almacén externo | el repositorio Git |
| Qué reside en Git | solo una referencia | secreto cifrado |
| Rotación | centralizada en el almacén, automática | volver a cifrar y confirmar el commit |
| Dependencia | el servicio externo debe estar accesible | clave del controlador en el clúster |
| Adecuado para | Vault existente, múltiples clústeres | GitOps puro sin almacén externo |
Para equipos con un almacén centralizado como HashiCorp Vault o un gestor de secretos en la nube, el External Secrets Operator suele ser la mejor opción. El secreto permanece en un único lugar, la rotación se gestiona allí y Kubernetes recibe únicamente una copia temporal. Quien quiera prescindir de un servicio externo y mantener todo en el repositorio, Sealed Secrets es la solución adecuada, aunque deberá proteger y rotar la clave del controlador en el clúster. Las propias herramientas también requieren mantenimiento: una vulnerabilidad notificada en 2026 en Sealed Secrets demuestra que incluso el mecanismo de protección puede ser objetivo de un parche.
Qué sostiene una gestión segura de secretos y qué la socava
Si un método protege de verdad o solo transmite una sensación de seguridad lo decide la implementación en los detalles. Los siguientes patrones distinguen lo uno de lo otro.
Qué socava
- Considerar el secreto en Base64 como protegido y dejar etcd sin cifrar
- Hacer commit de secretos una vez y confiar en eliminarlos más adelante
- Claves de larga duración sin rotación y sin fecha de expiración
- Mantener el acceso al controlador o al almacén tan amplio como el clúster normal
Qué sostiene
- Cifrar etcd y restringir estrictamente el acceso a la API
- No hacer commit de secretos en texto claro y utilizar un método de forma coherente
- Vigencia corta y rotación automática como estándar
- Mantener las claves del almacén y del controlador separadas y con permisos mínimos
El denominador común es una actitud sencilla: un secreto es tan seguro como el lugar en que peor está protegido. Descifrar Base64, cifrar etcd y aplicar un método de forma consistente supone menos esfuerzo que limpiar las consecuencias de una clave filtrada. Las herramientas son maduras y están disponibles de forma gratuita. Lo que falta, por lo general, es solo la decisión de tomarse el secreto más en serio que su codificación.
Preguntas frecuentes
¿Los Secrets de Kubernetes están cifrados?
Por defecto, no. Los valores se almacenan en etcd codificados en Base64, y Base64 es una codificación, no un cifrado. Quien tenga acceso a etcd o a la API puede leerlos en texto claro. El cifrado real en reposo debe activarse por separado para etcd, junto con permisos de acceso estrictos.
¿Qué hace el External Secrets Operator?
Lee secretos de un almacén externo como HashiCorp Vault, AWS Secrets Manager o Azure Key Vault y genera automáticamente Secrets nativos de Kubernetes a partir de ellos. La fuente de verdad permanece en el almacén; en el clúster solo existe una copia sincronizada. En el repositorio únicamente figura una referencia, nunca el secreto en sí.
¿Cómo funcionan los Sealed Secrets?
Un secreto se cifra con una clave pública que solo un controlador dentro del clúster puede descifrar. El objeto cifrado puede incluirse sin riesgo en el repositorio Git. El controlador lo descifra al aplicarlo en el clúster, convirtiéndolo en un Secret normal. Esto permite un GitOps auténtico sin almacenar ningún secreto en texto claro.
¿Qué método es el adecuado?
Depende de dónde deba residir la fuente de verdad. Si ya existe un almacén centralizado y varios clústeres, el External Secrets Operator es la opción idónea. Si se prefiere mantener todo en el repositorio sin depender de ningún servicio externo, los Sealed Secrets son el camino más sencillo. Ambos están consolidados; la diferencia está en la ubicación del secreto.
¿Qué ocurre con los secretos que ya están en Git?
Se consideran comprometidos y deben rotarse, no solo eliminarse. Borrarlos de la versión actual deja el secreto en el historial. La única solución segura es invalidar la clave o contraseña afectada y emitirla de nuevo; después, migrar el proceso a uno de los dos métodos seguros.
Fuente de la imagen: imagen de portada generada por IA (junio de 2026), certificado C2PA incorporado en la imagen
