← Todas las noticias
ARTÍCULO
19 de octubre de 2026 Actualizado el 13 de octubre de 2026 2 min de lectura

SOPS y Sealed Secrets: mantén el texto plano fuera de Git para Kubernetes de MSP

SOPS cifra los archivos de configuración antes de que lleguen a Git; Sealed Secrets cifra un Secret de Kubernetes para que solo el clúster de destino pueda descifrarlo. Juntos cubren el vacío de secretos en GitOps.

En este artículo
  1. Qué hace cada herramienta
  2. Dónde encajan y qué no sustituyen
  3. El hábito que merece la pena adoptar

getsops/sops y bitnami/sealed-secrets cubren un vacío habitual en los pipelines de GitOps: mantener los valores de los secretos fuera del texto plano en el control de versiones y, al mismo tiempo, permitir que, en el caso de Sealed Secrets, el clúster adecuado los descifre automáticamente.

Foto: Cromemco System Three in United Solder-Wrap Workstation
Foto: Cromemco System Three in United Solder-Wrap Workstation.jpg. Cromemco (CC BY-SA 4.0), Wikimedia Commons. https://commons.wikimedia.org/wiki/File%3ACromemco_System_Three_in_United_Solder-Wrap_Workstation.jpg https://creativecommons.org/licenses/by-sa/4.0/

Qué hace cada herramienta

SOPS cifra los archivos de configuración y de secretos antes de que se confirmen, mediante backends de tipo age, PGP o KMS en la nube. El acceso de descifrado lo controla quién posee la clave, con independencia de quién tenga acceso de lectura al repositorio. Sealed Secrets adopta un enfoque ligado al clúster: una herramienta del lado del cliente cifra un Secret de Kubernetes contra la clave pública del clúster de destino y genera un recurso personalizado SealedSecret que es seguro almacenar en Git. Solo el controlador dentro del clúster, que posee la clave privada correspondiente, puede convertirlo de nuevo en un Secret utilizable.

Dónde encajan y qué no sustituyen

Usadas en conjunto, las dos herramientas cubren mitades complementarias del mismo problema: SOPS protege archivos antes de que lleguen a Git, y Sealed Secrets protege el caso específico de un Secret de Kubernetes vinculado a un único clúster. Ninguna sustituye la rotación de credenciales, el control de acceso basado en roles ni el aislamiento de red: un SealedSecret es seguro de confirmar, pero sigue siendo texto cifrado para un límite de descifrado concreto, no un sustituto del acceso con privilegios mínimos. La higiene práctica importa aquí: restringe quién puede ejecutar una operación de descifrado en CI, no imprimas nunca valores descifrados en los registros de compilación y supervisa el estado del controlador de Sealed Secrets y su calendario de rotación de claves de sellado. Valida cualquier cambio en cualquiera de los dos pipelines en un clúster que no sea de producción antes de desplegarlo.

El hábito que merece la pena adoptar

El valor de cualquiera de las dos herramientas es el control que impone —el acceso mediante claves a archivos cifrados, o un límite de descifrado que solo un clúster puede cruzar—, no el nombre de la herramienta en una diapositiva. Fija las versiones, mantén los archivos cifrados revisables en las pull requests y trata la rotación de claves como una tarea programada y no como una respuesta a incidentes.

Fuentes: getsops/sops, bitnami/sealed-secrets.