Ir al contenido principal

ConfigMaps y Secrets en Kubernetes: Gestión de Configuraciones y Datos Sensibles.

En Kubernetes, es crucial manejar tanto la configuración de las aplicaciones como los datos sensibles de manera eficiente y segura. Para ello, Kubernetes nos proporciona dos tipos de recursos: ConfigMaps y Secrets. Ambos recursos permiten desacoplar la configuración y los datos sensibles de la lógica de la aplicación, lo que facilita su gestión y mantenimiento en entornos dinámicos, como los clústeres de Kubernetes.

A continuación, exploraremos cómo funcionan los ConfigMaps y los Secrets, cómo implementarlos y algunas prácticas recomendadas para su uso en Kubernetes.

ConfigMaps en Kubernetes

¿Qué es un ConfigMap?

Un ConfigMap es un recurso en Kubernetes diseñado para almacenar datos de configuración en forma de pares clave-valor. Estos datos pueden ser inyectados en los pods como variables de entorno o montados como archivos de configuración, permitiendo a los administradores cambiar la configuración de las aplicaciones sin modificar el código ni reconstruir las imágenes de los contenedores.

Características principales de los ConfigMaps:

  • Datos no sensibles: Los ConfigMaps están diseñados para almacenar datos no sensibles como configuraciones de parámetros, archivos de configuración y variables de entorno.
  • Desacoplamiento de la configuración: Permiten que la configuración esté separada del código de la aplicación, facilitando actualizaciones y cambios sin necesidad de reconstruir la aplicación.
  • Fácil actualización: Los ConfigMaps pueden actualizarse sin reiniciar los contenedores, lo que permite aplicar cambios de configuración de manera dinámica.

Creación de un ConfigMap

Puedes crear un ConfigMap desde un archivo o desde valores literales directamente en la línea de comandos. A continuación se muestra cómo hacerlo:

  1. Desde un archivo:

    kubectl create configmap my-config --from-file=application.properties

  2. Desde literales (pares clave-valor):

    kubectl create configmap my-config --from-literal=APP_ENV=production --from-literal=APP_DEBUG=false

Uso de ConfigMaps en Pods

Los ConfigMaps se pueden inyectar en los pods de dos maneras principales: como variables de entorno o montados como volúmenes.

Inyectar ConfigMap como variables de entorno:
yaml:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-app-image
    env:
    - name: APP_ENV
      valueFrom:
        configMapKeyRef:
          name: my-config
          key: APP_ENV

En este ejemplo, el valor de APP_ENV dentro del contenedor se extrae del ConfigMap my-config.

Montar ConfigMap como volúmenes:

Los ConfigMaps también pueden montarse como volúmenes en los pods, lo que permite que los archivos de configuración estén accesibles directamente en el sistema de archivos del contenedor.

yaml:

volumeMounts:
  - name: config-volume
    mountPath: /etc/config
volumes:
  - name: config-volume
    configMap:
      name: my-config

Esto montará el ConfigMap my-config en el directorio /etc/config dentro del contenedor, haciendo que los archivos de configuración estén disponibles en ese lugar.

Verificación del ConfigMap

Después de desplegar un ConfigMap en un pod, puedes verificar que se haya configurado correctamente. Por ejemplo, para verificar una variable de entorno inyectada:

bash:

kubectl exec -it my-pod -- /bin/bash
echo $APP_ENV

Esto debería mostrar el valor production si el ConfigMap se configuró correctamente.

Ejemplos y casos de uso:

Caso 1: Configuración del entorno de la aplicación

Escenario: Tienes una aplicación que necesita ejecutarse en diferentes entornos: producción, desarrollo y pruebas. Cada entorno puede tener valores distintos para algunas configuraciones.

Uso del ConfigMap: En lugar de codificar estos valores en tu contenedor (lo cual no es flexible ni seguro), puedes usar un ConfigMap para definir estas configuraciones.

ConfigMap:

kubectl create configmap app-config \
  --from-literal=APP_ENV=production \
  --from-literal=APP_VERSION=1.0

Manifiesto de Pod:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: my-app:latest
    env:
    - name: APP_ENV
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: APP_ENV
    - name: APP_VERSION
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: APP_VERSION

Cuando el Pod arranque, las variables de entorno estarán disponibles:

echo $APP_ENV      # production
echo $APP_VERSION  # 1.0

Beneficio:

  • Cambias el entorno de ejecución fácilmente actualizando el ConfigMap sin reconstruir la imagen o reiniciar el clúster.

Caso 2: Configuración de una base de datos

Escenario: Tu aplicación necesita conectarse a una base de datos, pero las credenciales y la URL cambian dependiendo del entorno.

ConfigMap:

kubectl create configmap db-config \
  --from-literal=DB_HOST=db.example.com \
  --from-literal=DB_PORT=5432 \
  --from-literal=DB_NAME=mydatabase

Manifiesto de Pod:

apiVersion: v1
kind: Pod
metadata:
  name: db-app
spec:
  containers:
  - name: app
    image: my-db-app:latest
    env:
    - name: DB_HOST
      valueFrom:
        configMapKeyRef:
          name: db-config
          key: DB_HOST
    - name: DB_PORT
      valueFrom:
        configMapKeyRef:
          name: db-config
          key: DB_PORT
    - name: DB_NAME
      valueFrom:
        configMapKeyRef:
          name: db-config
          key: DB_NAME

Ahora tu aplicación tendrá las variables necesarias para conectarse a la base de datos:

echo $DB_HOST  # db.example.com
echo $DB_PORT  # 5432
echo $DB_NAME  # mydatabase

Beneficio:

  • Los valores de configuración no están incrustados en la imagen, lo que facilita el cambio de configuración sin necesidad de recompilarla.

Caso 3: Proveer un archivo de configuración completo

Escenario: Tu aplicación necesita un archivo de configuración (por ejemplo, config.json o nginx.conf).

ConfigMap desde archivo:

kubectl create configmap nginx-config \
  --from-file=nginx.conf

Manifiesto de Pod:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest
    volumeMounts:
    - name: config-volume
      mountPath: /etc/nginx
  volumes:
  - name: config-volume
    configMap:
      name: nginx-config

Dentro del contenedor, el archivo estará disponible en /etc/nginx/nginx.conf.

Beneficio:

  • Facilita la gestión de configuraciones complejas en formato de archivo sin modificar la imagen.

Caso 4: Cambiar configuraciones en vivo

Escenario: Necesitas cambiar configuraciones de la aplicación mientras se está ejecutando sin reiniciar los contenedores.

Uso del ConfigMap: Actualiza el ConfigMap:

kubectl edit configmap app-config

Dependiendo de cómo esté implementada tu aplicación, puede detectar los cambios automáticamente (como un archivo montado).

Beneficio:

  • Ideal para aplicaciones que soportan recarga en caliente de configuraciones.

Resumen práctico

  1. Separación de configuración y código: Mantienes tu configuración fuera del código fuente.
  2. Flexibilidad: Puedes usar el mismo contenedor en diferentes entornos solo cambiando el ConfigMap.
  3. Eficiencia: Cambias configuraciones sin necesidad de crear nuevas imágenes o reiniciar todo el clúster.
  4. Escalabilidad: Centralizas la configuración para múltiples Pods o servicios.

Secrets en Kubernetes

¿Qué es un Secret?

Un Secret en Kubernetes es un recurso similar a un ConfigMap, pero está diseñado para almacenar datos sensibles, como contraseñas, claves de API, o certificados. A diferencia de los ConfigMaps, los Secrets están codificados en Base64, proporcionando una capa básica de ofuscación. Sin embargo, para asegurar que los Secrets estén protegidos, es recomendable cifrarlos y controlar su acceso mediante el control de acceso basado en roles (RBAC).

Características principales de los Secrets:

  • Almacenamiento de datos sensibles: Los Secrets están diseñados para gestionar información confidencial como credenciales de bases de datos, claves SSH, etc.
  • Codificación en Base64: Aunque no es un método de cifrado completo, la codificación Base64 ofusca los datos para que no estén en texto plano.
  • Control de acceso (RBAC): Los Secrets son gestionados mediante políticas de acceso basadas en roles para asegurar que solo los usuarios y servicios autorizados puedan acceder a ellos.

Creación de un Secret

Al igual que los ConfigMaps, puedes crear Secrets usando la línea de comandos:

  1. Desde literales (datos sensibles codificados en Base64):

    bash:


    kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secure123

Uso de Secrets en Pods

Al igual que los ConfigMaps, los Secrets pueden inyectarse en los pods como variables de entorno o montarse como volúmenes.

Inyectar Secret como variables de entorno:
yaml:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-app-image
    env:
    - name: DB_USERNAME
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: username
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: password

En este ejemplo, el nombre de usuario y la contraseña de la base de datos almacenados en el Secret my-secret se inyectan en el contenedor como variables de entorno.

Montar Secret como volúmenes:
yaml:


volumeMounts:
  - name: secret-volume
    mountPath: /etc/secret
volumes:
  - name: secret-volume
    secret:
      secretName: my-secret

Este ejemplo monta el Secret my-secret en el directorio /etc/secret dentro del contenedor, haciendo que los archivos de datos sensibles estén disponibles en esa ubicación.

Verificación de un Secret

Para verificar los datos almacenados en un Secret, puedes decodificarlos con el siguiente comando:

bash:

kubectl get secret my-secret -o yaml
echo "YWRtaW4=" | base64 --decode

Esto devolverá el valor original decodificado del Secret (por ejemplo, admin).

Diferencias clave entre ConfigMaps y Secrets

Aunque ambos recursos tienen funciones similares, existen algunas diferencias importantes:


Este artículo te proporciona una introducción a los ConfigMaps y Secrets, pero en los próximos artículos vamos a explorar cómo gestionarlos de manera más avanzada, como la integración con HashiCorp Vault para el manejo seguro de claves o cómo utilizar cert-manager para gestionar certificados TLS.

Comentarios

Publicar un comentario

Entradas populares de este blog

Autenticación y Autorización (Kubernetes).

La autenticación en Kubernetes es un aspecto crítico para la seguridad y control de acceso dentro de un clúster. Kubernetes proporciona varios mecanismos de autenticación para usuarios y cuentas de servicio, que deben pasar a través del API Server para realizar cualquier operación. En este artículo, revisaremos cómo funciona la autenticación y cómo puedes usar herramientas como kubectl y curl para interactuar de manera segura con el clúster. En primer lugar, ¿Qué es la autenticación y la autorización? •     Autenticación:  Es el proceso de verificar quién es un usuario. Responde a la pregunta "¿Quién eres?". •     Autorización: El proceso de determinar qué acciones puede realizar un usuario autenticado. Responde a la pregunta "¿Qué puedes hacer?". Primer paso: Autenticación. La autenticación en Kubernetes es el proceso mediante el cual el sistema verifica la identidad de los usuarios y cuentas de servicio que intentan acceder al clúster.  ...
Publicar un comentario
Leer más

Tip 1. Exámen CKA. Economiza y optimiza tu tiempo; Usa --help con el paginador Less en la ayuda.

📘 Domina los comandos --help y el uso de less en el examen CKA Durante el examen CKA (Certified Kubernetes Administrator) , uno de los recursos más potentes y completamente permitidos es el uso del --help en los comandos de Kubernetes. Además, puedes combinarlo con el paginador less para buscar y navegar fácilmente entre opciones. ✅ ¿Está permitido usar --help ? Sí, está 100% permitido . Puedes usar el --help de cualquier comando disponible en el entorno del examen: kubectl --help kubeadm init --help kubelet --help kubectl explain pod.spec.containers Estos comandos muestran la ayuda y las opciones disponibles directamente desde el sistema, sin necesidad de ir a la documentación. 🔍 ¿Cómo usar less para buscar rápidamente? Cuando la salida del comando es larga, puedes usar | less para verla de forma paginada y navegar más cómodamente. kubeadm init --help | less Una vez dentro de less , puedes buscar cualquier texto escribiendo /texto . Por ejemplo: /pod-networ...
Publicar un comentario
Leer más

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...
Publicar un comentario
Leer más