Ir al contenido principal

Cómo Representar Secrets en Kubernetes Usando Base64 y Cifrado AES-256

 

  Cuando trabajamos con Kubernetes, es fundamental proteger la información sensible, como contraseñas, claves API y tokens de acceso. Los Secrets en Kubernetes son una herramienta eficaz para almacenar estos datos sensibles, pero no están encriptados por defecto. Kubernetes usa Base64 para codificar los valores de los Secrets, lo cual no es encriptación sino una representación de los datos en un formato seguro y transportable. Para mejorar la seguridad, se recomienda cifrar los valores antes de convertirlos a Base64, y uno de los métodos más seguros es usar el cifrado AES-256.

En este artículo, veremos cómo generar un Secret en Kubernetes, encriptarlo con AES-256 y luego codificarlo en Base64 para que esté listo para usarse en un entorno Kubernetes.

¿Por Qué Usar Base64 en Kubernetes Secrets?

La codificación en Base64 convierte datos binarios o de texto en un formato de caracteres ASCII, lo cual facilita su almacenamiento y transporte. En Kubernetes, los valores de los Secrets están en formato Base64, lo que permite que los archivos YAML de configuración contengan datos sensibles sin interferir con la estructura del archivo.

Es importante recordar que Base64 no es encriptación. Es una forma de representación que hace los datos más manejables, pero no los protege contra accesos no autorizados. Por eso, para añadir una capa adicional de seguridad, puedes encriptar los datos sensibles antes de convertirlos a Base64.

Pasos para Crear un Secret Cifrado con AES-256 y Codificado en Base64

Paso 1: Generar una Clave AES-256

Para encriptar nuestros datos sensibles, primero necesitamos generar una clave AES-256. Puedes usar la herramienta openssl para esto. El siguiente comando genera una clave AES-256 aleatoria:

openssl rand -hex 32

El comando devolverá una clave hexadecimal de 32 bytes, que puedes usar para encriptar tu Secret. Aquí tienes un ejemplo de clave generada:

80a3284a8461ac72b8558f5d913b0e60e9c46f1ffe2cfbf645c16a312552e211

Paso 2: Cifrar el Valor del Secret con AES-256

Ahora que tienes una clave AES-256, puedes usarla para encriptar el valor de tu Secret. Supongamos que queremos almacenar una contraseña encriptada. Usaremos openssl enc para realizar el cifrado:

echo -n "mi-clave-secreta" | openssl enc -aes-256-cbc -K 80a3284a8461ac72b8558f5d913b0e60e9c46f1ffe2cfbf645c16a312552e211 -iv 00000000000000000000000000000000 | base64

En este ejemplo:

  • -aes-256-cbc especifica el tipo de cifrado AES-256 en modo CBC.
  • -K indica la clave hexadecimal que generaste.
  • -iv es el vector de inicialización. Aquí estamos usando 16 ceros, pero deberías cambiarlo en un entorno de producción.

La salida estará en Base64, y se verá algo como esto:

U2FsdGVkX1+zD+6P1aN3Z4yRqeMUkIQ==

Paso 3: Crear el Secret en un Archivo YAML

Ahora que tienes el valor encriptado y codificado en Base64, puedes crear el archivo YAML del Secret en Kubernetes. Asegúrate de que el valor esté en formato Base64. Aquí tienes un ejemplo de cómo debería verse el archivo YAML:

apiVersion: v1 kind: Secret metadata: name: mi-secret type: Opaque data: password: U2FsdGVkX1+zD+6P1aN3Z4yRqeMUkIQ==

En este archivo:

  • password es la clave del Secret.
  • U2FsdGVkX1+zD+6P1aN3Z4yRqeMUkIQ== es el valor encriptado y codificado en Base64 que generamos en el paso anterior.

Paso 4: Aplicar el Secret en el Clúster

Para crear el Secret en Kubernetes, usa el comando kubectl apply con el archivo YAML:

kubectl apply -f mi-secret.yaml

Esto almacenará el Secret en el clúster de Kubernetes. Puedes verificar que el Secret se haya creado correctamente ejecutando:

kubectl get secret mi-secret -o yaml

Paso 5: Acceder al Secret en un Pod

Una vez que el Secret esté almacenado en Kubernetes, puedes acceder a él en un Pod. Aquí tienes un ejemplo de cómo montar el Secret como una variable de entorno en un contenedor:

apiVersion: v1 kind: Pod metadata: name: demo-pod spec: containers: - name: demo-container image: alpine command: ["/bin/sh", "-c", "echo $(PASSWORD)"] env: - name: PASSWORD valueFrom: secretKeyRef: name: mi-secret key: password restartPolicy: Never

En este ejemplo:

  • El Secret mi-secret se monta como la variable de entorno PASSWORD en el contenedor demo-container.
  • El contenedor ejecutará un comando que imprime el valor de PASSWORD.

Aplica el Pod:

kubectl apply -f demo-pod.yaml

Y verifica los logs del Pod para ver el valor:

kubectl logs demo-pod

Ejemplo Completo: Crear un Secret Codificado en Base64 y Acceder desde un Pod

Aquí tienes un resumen completo de los pasos en un ejemplo:

  1. Generar la clave AES-256:

    secretKey=$(openssl rand -hex 32)
  2. Cifrar el Secret y codificarlo en Base64:


    encryptedValue=$(echo -n "mi-clave-secreta" | openssl enc -aes-256-cbc -K $secretKey -iv 00000000000000000000000000000000 | base64)
  3. Crear el archivo YAML del Secret:


    apiVersion: v1 kind: Secret metadata: name: mi-secret type: Opaque data: password: <valor_cifrado_base64>
  4. Aplicar el Secret y crear el Pod:

    kubectl apply -f mi-secret.yaml kubectl apply -f demo-pod.yaml

Consideraciones de Seguridad

  • Cifrado antes de Base64: Recuerda que la codificación en Base64 no es encriptación. Cifra primero la información sensible antes de codificarla en Base64.
  • Rotación de Claves: Cambia las claves de cifrado periódicamente para mejorar la seguridad.
  • Gestión de Secrets: Usa herramientas como Helm Secrets o herramientas de gestión de secretos en la nube (por ejemplo, AWS KMS o Google Secret Manager) para facilitar la administración de Secrets en entornos más complejos.

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...