ConfigMaps y Secrets en Kubernetes: Gestión de Configuraciones y Datos Sensibles. Bloque 2. Tema 2.4 del CKA.

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.

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