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
Secretcon una credencial de aplicación. - Crear un
ConfigMapcon 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
sudoo 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:
- Preparar el entorno.
- Crear los componentes necesarios.
- Configurar los manifiestos.
- Probar localmente.
- 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 appsCrear un ConfigMap con una variable no sensible:
kubectl create configmap app-config --from-literal=LOG_LEVEL=info -n appsAplicar el manifiesto que usa ambos recursos:
kubectl apply -f deployment-secrets.yamlValidar una variable de entorno dentro del despliegue:
kubectl exec deploy/api -n apps -- printenv | grep LOG_LEVELRevisar el secreto creado:
kubectl get secret app-db -o yaml -n appsConfiguració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_PASSWORDPaso 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 appsVerifica 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 appsVerifica 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_PASSWORDAntes 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_LEVELRevisa 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 appsSi 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.
