Las credenciales en repositorios o manifiestos planos suelen terminar expuestas durante despliegues, tareas de soporte o revisiones operativas. En Kubernetes, una forma conservadora de reducir ese riesgo es separar la configuración no sensible de los datos secretos, documentar cada cambio y validar el resultado antes de mover tráfico o datos reales.

Esta guía propone una implementación base con Secrets y ConfigMaps, pensada para adaptar a un Cloud Server de DonWeb Cloud, una instancia Linux propia o un entorno de laboratorio.

Arquitectura general propuesta para Kubernetes.

Qué vas a construir

Vas a preparar una configuración base en Kubernetes para:

  • Crear un Secret con una credencial de aplicación.
  • Crear un ConfigMap con una variable de configuración no sensible.
  • Referenciar ambos recursos desde un manifiesto de despliegue.
  • Validar que la aplicación recibe la configuración esperada.
  • Revisar el estado del secreto antes de pasar a un entorno más sensible.

El resultado esperado es una configuración documentada, con comandos de prueba y recomendaciones para avanzar desde laboratorio hacia producción.

Cuándo conviene usar este enfoque

Este flujo es útil cuando necesitas una solución operativa y repetible, no solo una explicación conceptual.

También conviene aplicarlo cuando:

  • El servicio va a vivir en un servidor cloud y requiere seguridad básica desde el primer despliegue.
  • Necesitas dejar evidencia de configuración, pruebas y criterios de mantenimiento.
  • Quieres reducir configuraciones manuales difíciles de auditar.
  • Buscas versionar manifiestos sin incluir credenciales reales.

Requisitos previos

Antes de comenzar, asegúrate de contar con:

  • Cloud Server o servidor Ubuntu/Debian actualizado.
  • Usuario con permisos sudo o rol equivalente.
  • Acceso SSH o consola segura.
  • Backup previo si el servidor ya tiene datos o tráfico real.
  • Dominio o subdominio si el artículo publica un servicio web.
  • Credenciales con mínimo privilegio si se usan comandos AWS.
  • Ventana de mantenimiento para cambios de red, firewall, runtime, base de datos o credenciales.

Arquitectura o flujo de trabajo

El flujo recomendado es:

  1. Preparar el entorno.
  2. Crear los componentes necesarios.
  3. Configurar los manifiestos.
  4. Probar localmente.
  5. Reforzar seguridad y documentar mantenimiento.

Evita cambiar varias capas a la vez. Si algo falla, una modificación incremental es más fácil de revisar y revertir.

Comandos principales

Crear un Secret para la contraseña de base de datos:

kubectl create secret generic app-db --from-literal=DB_PASSWORD='cambiar-esto' -n apps

Crear un ConfigMap con una variable no sensible:

kubectl create configmap app-config --from-literal=LOG_LEVEL=info -n apps

Aplicar el manifiesto que usa ambos recursos:

kubectl apply -f deployment-secrets.yaml

Validar una variable de entorno dentro del despliegue:

kubectl exec deploy/api -n apps -- printenv | grep LOG_LEVEL

Revisar el secreto creado:

kubectl get secret app-db -o yaml -n apps

Configuración base

En el manifiesto de la aplicación, puedes referenciar el ConfigMap y el Secret de esta forma:

envFrom:
  - configMapRef:
      name: app-config
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: app-db
        key: DB_PASSWORD

Paso 1: Preparar el servidor o entorno

Antes de ejecutar este paso, revisa que estés en el servidor correcto y que tengas una ventana de mantenimiento si el servicio ya recibe tráfico.

kubectl create secret generic app-db --from-literal=DB_PASSWORD='cambiar-esto' -n apps

Verifica la salida antes de continuar. Si el comando modifica red, credenciales, firewall, base de datos o runtime de contenedores, toma una copia de seguridad y conserva una ruta de rollback.

Paso 1: Preparar servidor o entorno.

Paso 2: Crear el ConfigMap

Crea un ConfigMap para separar la configuración no sensible de las credenciales.

kubectl create configmap app-config --from-literal=LOG_LEVEL=info -n apps

Verifica la salida antes de continuar. La configuración de aplicación puede versionarse, pero no debe mezclarse con secretos reales.

Paso 2: Instalar o activar componentes.

Paso 3: Configurar el manifiesto de despliegue

Referencia el ConfigMap y el Secret desde el manifiesto de la aplicación.

envFrom:
  - configMapRef:
      name: app-config
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: app-db
        key: DB_PASSWORD

Antes de aplicar cambios en un entorno con tráfico, conserva una versión anterior del manifiesto y define una ruta de rollback.

Paso 3: Configurar archivos y variables.

Paso 4: Probar que funciona

Valida que la aplicación recibe la configuración esperada.

kubectl exec deploy/api -n apps -- printenv | grep LOG_LEVEL

Revisa la salida antes de continuar. Evita imprimir credenciales completas en consola o logs durante las pruebas.

Paso 4: Probar funcionamiento.

Paso 5: Reforzar seguridad y dejar mantenimiento

Revisa el recurso creado y documenta cómo se mantendrá.

kubectl get secret app-db -o yaml -n apps

Si detectas credenciales expuestas, rota primero y luego investiga el alcance. También conviene dejar documentado quién puede ejecutar cambios y qué evidencia debe quedar después de cada modificación.

Paso 5: Reforzar seguridad y mantenimiento.

Problemas frecuentes

Permisos insuficientes

Revisa el usuario, el grupo, el rol IAM o el contexto de Kubernetes antes de repetir comandos con más privilegios.

Puerto ocupado o cerrado

Valida con ss -tulpn, reglas de firewall y security groups antes de asumir que la aplicación falló.

Variables de entorno ausentes

Confirma .env, secretos del orquestador y que no se impriman credenciales en logs.

El servicio inicia, pero no responde

Revisa healthchecks, logs, dependencia de base de datos y resolución DNS.

Rollback no definido

Conserva la versión anterior, snapshot, backup o manifiesto previo antes de aplicar cambios sensibles.

Buenas prácticas para producción

  • Usa mínimo privilegio para usuarios, roles, contenedores y reglas de red.
  • Versiona configuraciones sin incluir secretos.
  • Prueba restauraciones de backup, no solo la creación del archivo.
  • Activa logs y alertas antes de necesitar diagnosticar un incidente.
  • Documenta quién puede ejecutar cambios y qué evidencia debe quedar.
  • Revisa periódicamente dependencias, imágenes y paquetes del sistema.

Advertencias de seguridad

No ejecutes estos pasos contra infraestructura de terceros ni contra producción sin autorización.

Los comandos de seguridad se orientan a defensa, mitigación y auditoría autorizada. Si detectas credenciales expuestas, rota primero y luego investiga el alcance.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

  • Performance que te sorprenderá
  • Rápida escalabilidad y sin limitaciones
  • Arquitectura de alta disponibilidad
  • Soporte experto y ejecutivos de cuenta
  • Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting