Saltar al contenido principal

Capítulo 5.4 - Buenas Prácticas

Objetivos de Aprendizaje​

Al final de este capítulo, usted será capaz de:

  • Aplicar buenas prácticas para ConfigMaps
  • Gestionar los secrets de manera segura
  • Comprender los límites y restricciones
  • Implementar la rotación de secrets
  • Utilizar External Secrets Operator
  • Configurar el cifrado en reposo

Introducción​

Las buenas prácticas para ConfigMaps y Secrets son esenciales para mantener un entorno Kubernetes seguro, mantenible y eficiente.


ConfigMaps: Buenas Prácticas​

1. Separación de la Configuración​

No codificar directamente en el código:

# ❌ Malo
env:
- name: DATABASE_URL
value: "postgresql://localhost:5432/mydb"

# ✅ Bueno
env:
- name: DATABASE_URL
valueFrom:
configMapKeyRef:
name: app-config
key: database_url

2. Organización por Entorno​

Crear ConfigMaps separados por entorno:

# Dev
kubectl create configmap app-config-dev --from-file=config-dev.properties

# Producción
kubectl create configmap app-config-prod --from-file=config-prod.properties

3. Versionado​

Utilizar labels para versionar:

metadata:
name: app-config
labels:
version: v1
environment: production

Secrets: Buenas Prácticas​

1. Nunca Hacer Commit​

❌ Nunca hacer:

  • Hacer commit de secrets en Git
  • Poner secrets en texto plano en los YAML
  • Compartir secrets por email/chat

✅ Hacer:

  • Utilizar herramientas de gestión de secrets
  • Cifrar los secrets en reposo
  • Utilizar External Secrets Operator

2. Rotación Regular​

# Crear un nuevo secret
kubectl create secret generic db-secret-v2 \
--from-literal=password=new-password

# Actualizar el Deployment
kubectl set env deployment/my-app \
DB_PASSWORD=$(kubectl get secret db-secret-v2 -o jsonpath='{.data.password}' | base64 -d)

# Eliminar el secret antiguo
kubectl delete secret db-secret-v1

3. Cifrado en Reposo​

Kubernetes almacena los secrets en base64 (sin cifrado por defecto).

Soluciones:

  • Activar el cifrado en reposo (EncryptionConfig)
  • Utilizar herramientas externas (Vault, AWS Secrets Manager)

Límites y Restricciones​

Tamaño Máximo​

  • ConfigMap: 1 MiB por entrada
  • Secret: 1 MiB por entrada
  • Total: Limitado por etcd (generalmente 1.5 MiB)

Rendimiento​

  • Los ConfigMaps grandes pueden ralentizar el inicio de los Pods
  • Preferir varios ConfigMaps pequeños

External Secrets Operator​

Para secrets externos (AWS, Azure, GCP, Vault):

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: db-secret
spec:
secretStoreRef:
name: aws-secrets-manager
kind: SecretStore
target:
name: db-secret
creationPolicy: Owner
data:
- secretKey: password
remoteRef:
key: production/database/password

Resumen​

En este capítulo, usted ha aprendido:

ConfigMaps: Separar configuración del código, organizar por entorno
Secrets: Nunca hacer commit, rotación regular, cifrado
Límites: Tamaño máximo, consideraciones de rendimiento
Herramientas: External Secrets Operator para secrets externos
Seguridad: Cifrado en reposo, gestión centralizada


Próximos Pasos​

Lab 5.1: Creación y Uso de ConfigMaps
Lab 5.2: Gestión de Secrets


Capítulo creado el: Diciembre 2024