Problema

En entornos donde conviven servidores Linux, clústers de Kubernetes, contenedores Docker y bases de datos, es habitual que cada capa tenga su propia herramienta de acceso: un cliente SSH para servidores, docker o Portainer para contenedores, kubectl o una UI para Kubernetes, y clientes específicos para bases de datos o escritorios remotos. Cuando el número de recursos crece, el flujo de trabajo se vuelve una cadena de aperturas y cierres de aplicaciones, credenciales dispersas y sesiones que no quedan registradas de forma central.

Este patrón genera varios síntomas:

  • Pérdida de tiempo al alternar entre 8‑10 clientes diferentes.
  • Dificultad para aplicar políticas de acceso coherentes (RBAC, MFA).
  • Falta de auditoría unificada: los logs de SSH, Docker y bases de datos están en lugares distintos.
  • Incremento del “technical debt” porque cada herramienta necesita su propio proceso de actualización y backup.

Cualquier equipo que administre más de unos pocos nodos o que mantenga entornos híbridos (on‑prem + cloud) termina con una experiencia de gestión fragmentada que impacta en la velocidad de respuesta y en la seguridad operativa.

Causa

Los orígenes de esta fragmentación son varios y se combinan en la práctica:

  1. Herramientas especializadas por diseño – Cada proyecto (Docker, Kubernetes, Proxmox, etc.) entrega su propio cliente porque el alcance funcional es diferente.
  2. Credenciales aisladas – Las claves SSH, tokens de Kubernetes y contraseñas de bases de datos se guardan en archivos o gestores distintos, lo que dificulta una política única de rotación y encriptado.
  3. Ausencia de capa de orquestación de acceso – En muchos setups no existe un “gateway” que actúe como punto de entrada y delegue la autenticación a los backends.
  4. Falta de integración de auditoría – Los logs de sesión se generan en cada herramienta, pero rara vez se consolidan en un repositorio central para cumplimiento.
  5. Despliegues ad‑hoc – Cuando se necesita una nueva funcionalidad (por ejemplo, acceso a una base de datos), se instala una herramienta adicional sin evaluar la posibilidad de ampliarla mediante plugins o extensiones.

Solución

Una forma de romper este ciclo es implementar un gateway auto‑hosted que sirva como punto único de entrada para los protocolos más comunes (SSH, SFTP, Docker, Kubernetes, bases de datos, RDP). El gateway actúa como un proxy autenticado que delega la conexión al backend correspondiente, registra la sesión y aplica políticas de control de acceso basadas en roles.

Arquitectura mínima

[Usuario] → HTTPS (gateway) → {SSH, Docker, K8s, DB, RDP}
  • Frontend: una UI ligera (React, Vue) embebida en el binario para que los usuarios inicien sesiones desde el navegador.
  • Backend: un proceso Go que expone endpoints para cada protocolo, gestiona la encriptación de credenciales y escribe logs estructurados.
  • Almacenamiento de credenciales: un vault interno (por ejemplo, HashiCorp Vault o gocrypt) que guarda claves en reposo cifradas.
  • Control de acceso: roles definidos en un archivo YAML o base de datos ligera; el gateway verifica permisos antes de abrir la conexión.
  • Extensibilidad: un marketplace de plugins que permite añadir nuevos protocolos sin recompilar el binario.

Implementación práctica con Docker

  1. Construir la imagen – La mayoría de los proyectos ofrecen una imagen oficial que ya incluye el binario y el frontend.
  2. Persistir datos – Montar volúmenes para la base de datos de usuarios, los logs y el vault.
  3. Exponer puertos – El gateway escucha en 443 (HTTPS) y, opcionalmente, en 2222 para túneles SSH directos.
  4. Configurar variables de entorno – Definir GATEWAY_ADMIN_PASSWORD, VAULT_KEY, y la lista de backends (hosts, puertos, certificados).

Esta arquitectura permite que cualquier cliente (navegador, ssh -J, docker CLI) se conecte a través del gateway, manteniendo la experiencia de línea de comandos pero con una capa de control centralizada.

Cuándo aplicar esta solución

Señales de que el gateway es apropiado

  • Múltiples protocolos – Necesitas acceso a SSH, Docker y Kubernetes desde la misma máquina de gestión.
  • Política de auditoría – Debes conservar un registro completo de quién hizo qué y cuándo, con capacidad de búsqueda.
  • Control de acceso granular – Diferentes equipos (dev, ops, DBA) requieren permisos distintos sobre los mismos recursos.
  • Entorno distribuido – Los recursos están en varios data centers o nubes y no quieres abrir puertos directos a cada uno.

Escenarios donde no aporta valor

  • Infraestructura monolítica – Solo un par de servidores con acceso SSH y sin contenedores.
  • Equipos pequeños sin requisitos de auditoría – El overhead de gestionar un gateway puede ser mayor que el beneficio.
  • Políticas de red que prohíben proxies – Algunas organizaciones requieren conexiones directas por cumplimiento.

Código

docker run -d \
  --name shellcn-gateway \
  -p 443:443 \
  -p 2222:2222 \
  -v /opt/shellcn/data:/app/data \
  -e GATEWAY_ADMIN_PASSWORD=SuperSecreto123 \
  -e VAULT_KEY=clave-de-vault-256bits \
  ghcr.io/charlesng35/shellcn:latest
  • -v /opt/shellcn/data:/app/data persiste usuarios, credenciales y logs.
  • Las variables GATEWAY_ADMIN_PASSWORD y VAULT_KEY deben generarse con un gestor de contraseñas y mantenerse fuera del control de versiones.
  • Después de iniciar el contenedor, accede a https://<host> para crear roles, usuarios y backends.

## Verificación
1. **Acceso web** – Navega a `https://<host>` y verifica que la UI carga sin errores de certificado.  
2. **Login** – Inicia sesión con el usuario admin creado en la primera ejecución.  
3. **Prueba SSH** – Desde la UI, abre una sesión SSH a uno de los servidores registrados; la terminal debería aparecer en el navegador y, simultáneamente, un archivo JSON con la sesión debe aparecer en `/opt/shellcn/data/logs`.  
4. **Docker** – Ejecuta `docker ps` a través del terminal embebido; los contenedores del host remoto deben listarse.  
5. **Kubernetes** – Usa `kubectl get pods` dentro de la sesión; verifica que el contexto se haya cargado correctamente.  
6. **Auditoría** – Busca en los logs la entrada correspondiente a la sesión SSH; confirma que incluye usuario, timestamp y comando ejecutado.

Si alguno de los pasos falla, revisa los volúmenes montados y los permisos del archivo de configuración (`/app/data/config.yaml`). Los logs del contenedor (`docker logs shellcn-gateway`) suelen indicar problemas de conexión a backends o errores de desencriptado de credenciales.

## Notas adicionales
* **Rotación de claves** – Programa una tarea cron que regenere `VAULT_KEY` cada 90 días y actualice los secretos en el vault; el gateway recarga automáticamente sin downtime.  
* **Escalado** – En entornos con alta concurrencia, despliega el gateway detrás de un balanceador (HAProxy, Traefik) y habilita la opción de “sticky sessions” para que los logs se escriban en un storage compartido (NFS o S3).  
* **Plugins** – Si necesitas acceso a un nuevo tipo de base de datos (por ejemplo, MongoDB), busca en el marketplace del proyecto o escribe un plugin Go que implemente la interfaz `BackendProvider`.  
* **Seguridad** – Habilita MFA para la cuenta admin y usa certificados client‑side para los usuarios que requieran acceso sin contraseña.  
* **Backup** – Copia periódicamente el directorio `/opt/shellcn/data` a un repositorio off‑site; incluye tanto la base de datos de usuarios como los logs de auditoría.  

Con un gateway auto‑hosted bien configurado, la fricción operativa disminuye significativamente, la seguridad se vuelve más manejable y la trazabilidad de acciones queda centralizada, lo que facilita tanto el día a día del equipo como auditorías externas.