DOCKER - TELEPORT

 

🔐🖥️ Bastión SSH con Teleport y Docker: acceso remoto seguro y auditado

En esta práctica se despliega Teleport como bastión SSH utilizando Docker, y se une un segundo servidor al clúster como agente/nodo, de forma que el acceso por SSH a ese servidor deja de depender de claves sueltas repartidas entre distintas personas y pasa a gestionarse de forma centralizada, con usuarios nominales, doble factor de autenticación y registro de cada sesión.

El escenario parte de una infraestructura sencilla pero muy habitual: un servidor con Docker que hace de punto de entrada, y otro servidor "de producción" al que normalmente se accedería por SSH directo. En lugar de abrir el puerto 22 de ese segundo servidor hacia el exterior, se instala en él un agente ligero de Teleport que inicia una conexión saliente hacia el bastión. El resultado es que el servidor protegido no necesita ningún puerto entrante abierto, y todo el acceso pasa, de forma auditada, a través del bastión.

🧰 Tecnologías empleadas

Teleport Teleport es la pieza central de la práctica. Actúa como autoridad certificadora interna, como proxy de acceso y como punto único de autenticación para todos los servidores que se vayan añadiendo al clúster. En lugar de gestionar claves SSH estáticas por servidor, Teleport emite certificados de corta duración cada vez que un usuario inicia sesión, de manera que el acceso se revoca automáticamente cuando el certificado caduca o cuando se elimina el usuario.

Una de las ventajas de Teleport frente a un bastión SSH clásico es que centraliza en un único lugar la autenticación, el registro de sesiones y la lista de servidores accesibles, sin necesidad de mantener claves públicas distribuidas manualmente en cada máquina.

Docker y Docker Compose El componente central de Teleport (el que hace de autenticación y proxy) se despliega en un contenedor Docker gestionado con Compose. Esto permite levantar, actualizar o reconstruir el bastión sin tocar el sistema operativo base, y mantener la configuración y los datos del clúster en volúmenes persistentes independientes del ciclo de vida del contenedor.

Certificado TLS autofirmado Al no requerir un dominio público para esta práctica, Teleport genera automáticamente un certificado autofirmado para su interfaz web. Esto simplifica el despliegue en un laboratorio, aunque implica que tanto el navegador como el cliente de línea de comandos avisen de que el certificado no proviene de una autoridad reconocida. Más adelante se explica por qué esto no compromete la seguridad del proceso de unión de nuevos servidores.

MFA con OTP Además de usuario y contraseña, Teleport exige un segundo factor de autenticación basado en códigos de un solo uso (OTP), compatible con aplicaciones como Google Authenticator o Authy. Esto añade una capa adicional de protección incluso si la contraseña de un usuario quedara comprometida.

Ubuntu Server Ambos servidores de la práctica ejecutan Ubuntu Server: uno con Docker, encargado de alojar el bastión, y otro sin ningún requisito adicional, que simplemente recibe el agente de Teleport para pasar a formar parte del clúster.

🎯 Objetivos de la práctica

El objetivo principal es sustituir el acceso SSH directo y disperso por un modelo de acceso centralizado, auditable y con revocación sencilla, sin necesidad de exponer puertos SSH adicionales en los servidores protegidos.

De forma más concreta, se busca desplegar el componente de autenticación y proxy de Teleport en Docker, unir un segundo servidor como nodo del clúster mediante un token de invitación de un solo uso, crear un usuario administrador con doble factor, y validar que ese usuario puede conectarse por SSH al nodo tanto desde la interfaz web como desde la línea de comandos.

🧩 Desarrollo de la práctica

Despliegue del bastión en Docker El primer paso consiste en definir la configuración del clúster: qué componentes se activan (autenticación y proxy) y en qué puertos escuchan. Esta configuración se entrega al contenedor mediante un volumen, junto con otro volumen persistente donde Teleport guarda su propio estado, sus certificados internos y sus claves. Separar configuración y datos en volúmenes distintos permite reconstruir o actualizar el contenedor sin perder el clúster ya creado.

Firewall del bastión Una vez definida la configuración, se abren en el firewall del bastión únicamente los puertos estrictamente necesarios: uno para la interfaz web y el acceso de los usuarios, y otro para el servicio de autenticación interno que utilizan los nuevos servidores al unirse. El resto de puertos permanece cerrado, reduciendo la superficie expuesta.

Creación del primer usuario y alta de MFA Con el bastión en marcha, se crea el primer usuario administrador indicando qué roles tendrá dentro de Teleport y con qué usuario del sistema operativo podrá iniciar sesión en los servidores del clúster. Teleport genera automáticamente un enlace de invitación de un solo uso: al abrirlo, el usuario define su contraseña y registra el segundo factor escaneando un código QR desde su aplicación de autenticación.

Instalación del cliente de línea de comandos En el equipo desde el que se va a administrar el clúster se instala el cliente oficial de Teleport, que permite iniciar sesión, listar los servidores disponibles y conectarse por SSH sin salir de la terminal, de forma equivalente a como se haría con un cliente SSH tradicional, pero pasando siempre por la autenticación centralizada del bastión.

Instalación y unión del agente en el segundo servidor En el servidor que se quiere proteger se instala el mismo binario de Teleport, pero configurado únicamente con el rol de nodo SSH. Para incorporarlo al clúster, el bastión genera un token de invitación de un solo uso con caducidad corta, junto con la huella criptográfica de su propia autoridad certificadora. El agente utiliza esos dos valores para autenticarse frente al servicio de autenticación del bastión y solicitar sus propios certificados internos. A partir de ese momento, el agente mantiene una conexión saliente permanente hacia el bastión, por lo que el servidor protegido no necesita ningún puerto entrante abierto.

Concesión de acceso SSH Una vez que el nodo aparece registrado en el clúster, se actualiza el usuario administrador para indicarle con qué cuenta del sistema operativo puede iniciar sesión en ese servidor concreto. Esta separación entre la identidad en Teleport y el usuario Unix final permite que una misma persona pueda tener distintos logins según el servidor al que se conecte.

Validación de extremo a extremo Por último, se valida el flujo completo: inicio de sesión del usuario en el bastión, listado de servidores disponibles y conexión SSH efectiva al nodo, tanto desde la interfaz web como desde el cliente de terminal. Esta doble validación confirma que el acceso funciona igual de bien para un uso ocasional desde el navegador que para un uso intensivo desde la línea de comandos.

🔍 ¿Por qué es importante esta práctica?

El acceso remoto a servidores es una necesidad constante en cualquier infraestructura, pero también uno de los puntos más delicados desde el punto de vista de la seguridad. Un modelo basado en claves SSH sueltas, repartidas manualmente y sin caducidad, dificulta saber quién tiene acceso a qué, cuándo se conectó y qué hizo durante la sesión.

Teleport resuelve este problema centralizando la autenticación y sustituyendo las claves estáticas por certificados de corta duración. Cuando se elimina o se desactiva un usuario, su acceso desaparece de forma inmediata en todos los servidores del clúster, sin necesidad de ir servidor por servidor revocando claves.

Además, al ejecutarse en Docker, el propio bastión resulta sencillo de mantener, actualizar y, si fuera necesario, reconstruir desde cero conservando el estado del clúster en los volúmenes persistentes.

✅ Resultados esperados

Al finalizar la práctica, el bastión estará operativo en Docker, con su interfaz web accesible y protegida con usuario, contraseña y doble factor. El segundo servidor aparecerá registrado como nodo del clúster, sin ningún puerto SSH expuesto directamente hacia la red desde la que se accede.

El usuario administrador podrá autenticarse tanto desde el navegador como desde el cliente de línea de comandos, y en ambos casos podrá establecer una sesión SSH contra el nodo utilizando el usuario del sistema operativo previamente autorizado.

🏢 Propuesta empresarial

Clockwork Computer necesita ordenar el acceso remoto a sus servidores internos. Hasta ahora, el acceso se realizaba mediante claves SSH distribuidas manualmente entre los técnicos, sin un control centralizado de quién tenía acceso a cada máquina ni un registro claro de la actividad realizada durante las sesiones.

El departamento de IT ha decidido implementar un bastión SSH basado en Teleport, desplegado en Docker sobre uno de los servidores existentes, e ir incorporando el resto de servidores de la infraestructura como nodos del clúster a medida que se complete la migración.

📌 Escenario propuesto

Clockwork Computer dispone de un servidor con Docker que actuará como bastión de acceso, y de al menos un segundo servidor "de producción" al que actualmente se accede por SSH directo. El objetivo es que ese segundo servidor deje de ser accesible directamente y pase a gestionarse a través del bastión.

🎯 Requisitos técnicos solicitados por la empresa

La empresa solicita implementar las siguientes tareas:

• Desplegar el componente de autenticación y proxy de Teleport en Docker sobre el servidor bastión.
• Definir en el firewall del bastión únicamente los puertos estrictamente necesarios para la interfaz web y para el registro de nuevos servidores.
• Crear un usuario administrador con doble factor de autenticación (OTP) para el acceso a Teleport.
• Instalar el cliente de línea de comandos de Teleport en el equipo de administración.
• Instalar el agente de Teleport en el segundo servidor, configurado exclusivamente con el rol de nodo SSH.
• Generar un token de invitación de un solo uso y unir el nodo al clúster sin necesidad de abrir puertos entrantes en ese servidor.
• Asociar al usuario administrador el login del sistema operativo correspondiente en el nuevo nodo.
• Validar el acceso SSH de extremo a extremo, tanto desde la interfaz web como desde el cliente de terminal.
• Revisar el registro de actividad del clúster para confirmar la trazabilidad de las conexiones.

🔐 Justificación técnica y de seguridad

Clockwork Computer necesita ordenar el acceso remoto sin añadir complejidad operativa innecesaria. Teleport permite resolver esta necesidad centralizando la autenticación de todos los servidores en un único punto, sustituyendo las claves SSH estáticas por certificados de corta duración emitidos en cada inicio de sesión.

El uso de un token de invitación de un solo uso, combinado con la huella criptográfica de la autoridad certificadora del clúster, permite incorporar nuevos servidores de forma segura sin depender de la validación tradicional de certificados TLS, lo cual resulta especialmente útil en despliegues internos que todavía no cuentan con un dominio propio.

El doble factor de autenticación añade una capa adicional de protección frente al robo o filtración de contraseñas, y el hecho de que los servidores protegidos no necesiten ningún puerto entrante abierto reduce de forma notable la superficie de ataque expuesta hacia el resto de la red.

🧪 Validación esperada

Al finalizar la práctica, Clockwork Computer deberá comprobar que el usuario administrador puede autenticarse correctamente en el bastión con contraseña y OTP, que el segundo servidor aparece registrado como nodo del clúster, y que es posible establecer una sesión SSH contra ese nodo tanto desde la interfaz web como desde el cliente de línea de comandos, sin que el servidor protegido tenga ningún puerto SSH expuesto directamente.

✅ Resultado empresarial esperado

Como resultado final, Clockwork Computer dispondrá de un modelo de acceso remoto centralizado basado en Teleport, desplegado sobre Docker. El acceso a los servidores internos dejará de depender de claves SSH sueltas y pasará a gestionarse mediante usuarios nominales, doble factor de autenticación y certificados de corta duración, con la posibilidad de ir incorporando el resto de la infraestructura como nodos del mismo clúster a medida que avance la migración.

Esta práctica representa un caso real de modernización del acceso remoto, evaluando la capacidad de diseñar, desplegar y validar un bastión SSH seguro, auditable y preparado para crecer junto con la infraestructura de la empresa.

🔗 Enlaces de interés

      DOCUMENTACIÓN     

⚙️ Estructura de red