Ir al contenido principal

Generación y Encriptación de Secrets en Kubernetes con Helm y PGP

 Cuando trabajamos con Kubernetes, es fundamental proteger la información sensible de nuestras aplicaciones, como contraseñas, tokens, y claves API. Para esto, Kubernetes nos permite usar Secrets. Sin embargo, a menudo los Secrets en su forma básica no están cifrados en reposo, lo que puede representar un riesgo de seguridad. En este artículo, exploraremos cómo usar Helm junto con PGP (Pretty Good Privacy) para cifrar valores sensibles en archivos YAML, manteniéndolos seguros.

¿Por qué cifrar Secrets en Kubernetes?

Los Secrets de Kubernetes se almacenan en formato Base64, lo cual no es una verdadera encriptación. Aunque Base64 hace que los valores sean menos visibles, cualquiera que acceda al archivo puede decodificarlos fácilmente. Con herramientas como Helm Secrets y PGP, podemos encriptar estos datos de una manera más segura, haciendo más difícil su acceso sin las claves adecuadas.

Requisitos Previos

Antes de empezar, necesitas:

  • Tener Helm instalado en tu sistema.
  • Tener el plugin Helm Secrets instalado.
  • Tener acceso a GnuPG (gpg) para crear y gestionar claves PGP.

Instalación de Helm y Helm Secrets

Si aún no tienes Helm, puedes instalarlo ejecutando:

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh

Luego, instala el plugin Helm Secrets:

helm plugin install https://github.com/jkroepke/helm-secrets

Paso 1: Creación de una Clave PGP

Para cifrar un Secret con Helm, primero necesitamos una clave PGP. Puedes crear una nueva clave ejecutando el siguiente comando:

gpg --generate-key

Este comando te guiará por una serie de opciones, incluyendo:

  • El tipo de clave (recomendado: RSA and RSA).
  • Tamaño de la clave (ej. 4096 bits).
  • Tiempo de expiración.
  • Nombre y correo asociado a la clave.

Al finalizar, tendrás una clave PGP con una clave pública y una privada. La clave pública puede compartirse y usarse para encriptar, mientras que la clave privada es necesaria para desencriptar.

Nota: Puedes listar las claves disponibles con gpg --list-keys.

Paso 2: Configurar un Archivo .sops.yaml

Para decirle a Helm Secrets qué clave PGP usar, necesitamos configurar un archivo .sops.yaml. Este archivo define qué reglas de encriptación se aplicarán. En el caso de una clave PGP, el archivo se vería así:

creation_rules: - pgp: > tu-id-de-clave-pgp

Reemplaza tu-id-de-clave-pgp con el ID de la clave que creaste en el paso anterior. Puedes encontrar este ID listando las claves con gpg --list-keys.

Paso 3: Crear un Archivo YAML con Valores Sensibles

Crea un archivo llamado values.yaml que contenga los valores sensibles que quieres cifrar. Por ejemplo:

jwt-key: value: "secret-key"

Este archivo contiene el valor secret-key que queremos proteger.

Paso 4: Cifrar el Archivo YAML con Helm Secrets

Ahora que tenemos la clave PGP y el archivo .sops.yaml configurado, podemos cifrar el archivo values.yaml con el siguiente comando:

helm secrets enc values.yaml

Este comando encripta los valores usando la clave PGP especificada y genera un archivo YAML cifrado. El archivo resultante podría verse así:


jwt-key: value: ENC[AES256_GCM,data:...,tag:...,type:str] sops: pgp: | -----BEGIN PGP MESSAGE----- ... -----END PGP MESSAGE----- version: 3.7.3

Los valores ahora están encriptados y solo pueden ser desencriptados por alguien que tenga la clave PGP privada correspondiente.

Paso 5: Desencriptar y Usar el Archivo Cifrado

Cuando necesites usar el archivo cifrado en un despliegue, Helm Secrets se encarga de desencriptarlo temporalmente. Para ejecutar un despliegue con valores encriptados, puedes usar:


helm secrets install mi-aplicacion ./chart -f values.yaml

Helm desencriptará los valores en values.yaml durante el despliegue, pero los mantendrá cifrados en reposo.

Ventajas de Usar Helm Secrets y PGP

  1. Seguridad Mejorada: Los valores sensibles están cifrados y solo pueden desencriptarse con la clave privada.
  2. Integración Sencilla: Helm Secrets facilita la integración con Helm, permitiendo el uso de archivos cifrados en despliegues.
  3. Flexibilidad en la Configuración: Podemos usar distintos métodos de encriptación (no solo PGP) dependiendo de las necesidades de nuestro entorno.

Comentarios

Entradas populares de este blog

Ubicación, Estructura y Manejo básico de certificados.

                                                     Kubernetes utiliza certificados TLS (X.509) para cifrar la comunicación entre sus componentes y autenticar identidades (usuarios, nodos, API Server, etc.). Estos certificados son generados y gestionados automáticamente cuando se instala un clúster con kubeadm . En este artículo, veremos dónde se almacenan los certificados , cuál es su estructura y cómo inspeccionarlos fácilmente, una habilidad muy útil para el examen CKA. Cuando creas un clúster con kubeadm , los certificados se generan por defecto en el directorio: /etc/ kubernetes /pki/ Puedes ver su contenido con: ls -l /etc/kubernetes/pki/ También hay certificados en: /etc/kubernetes/ (ahí verás admin.conf , kubelet.conf , etc., que incluyen certificados embebidos, como veremos más abajo). 🧱 Estructura de los ce...

🔁 Renovación y Rotación de Certificados en Kubernetes (kubeadm certs)

  🎯 Introducción En un clúster de Kubernetes, la mayoría de los certificados generados por kubeadm tienen una validez de un año . Para evitar interrupciones en los componentes críticos, es fundamental revisar periódicamente su vigencia y saber cómo renovarlos correctamente. En este artículo aprenderás: Cómo comprobar la expiración de los certificados Cómo renovarlos automáticamente con kubeadm Cómo simular una renovación manual con openssl Cómo aplicar los cambios reiniciando los componentes afectados 🕵️‍♂️ Comprobación del estado de los certificados Kubernetes ofrece una herramienta integrada para revisar los certificados del clúster: kubeadm certs check-expiration Este comando muestra información clave: Fecha de expiración Tipo de certificado Ruta en el sistema 📌 Salida de ejemplo: CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY apiserver Jan 06 , 2026 19 :56 UTC 330d ...

TLS Bootstrapping en Kubernetes: Qué es, cómo funciona y por qué importa en el examen CKA

                                                       Uno de los conceptos que a menudo pasan desapercibidos en la administración de Kubernetes —pero que resultan clave tanto en entornos reales como en el examen CKA— es el TLS Bootstrapping . En este artículo entenderás qué es, cómo funciona, qué lo diferencia del kubeadm join tradicional y cómo puede aparecer en el examen. ¿Qué es TLS Bootstrapping? TLS Bootstrapping es el proceso por el cual el kubelet , el agente que corre en cada nodo, obtiene automáticamente un certificado TLS firmado por el clúster para autenticarse con el kube-apiserver . En otras palabras: permite que un nuevo nodo se una de forma segura al clúster sin necesidad de copiar manualmente los certificados. ¿Por qué es necesario? Cuando añades un nuevo nodo worker, su kubelet necesita autentic...