Implementando PAM Open Source con JumpServer en un laboratorio Proxmox y MicroK8s

Un homelab normalmente comienza de forma sencilla: algunas máquinas virtuales, llaves SSH, quizá un clúster de Kubernetes y una VPN para acceder remotamente.

Después, la infraestructura empieza a crecer.

En mi caso, mi laboratorio incluye múltiples sistemas ejecutándose sobre Proxmox y clústeres de MicroK8s. Conforme aumenta la cantidad de servidores, servicios, bases de datos y workloads de Kubernetes, administrar los accesos privilegiados únicamente mediante llaves SSH y cuentas administrativas se vuelve cada vez más difícil de controlar y auditar.

Esto plantea una pregunta importante:

¿Cómo puedo controlar, centralizar y auditar el acceso privilegiado a mi laboratorio sin implementar una costosa solución empresarial de PAM?

La respuesta que decidí explorar es Privileged Access Management (PAM) utilizando software open source.

En este artículo explicaré el problema que quiero resolver, qué proporciona PAM, las alternativas open source que consideré —incluyendo Teleport— y por qué decidí comenzar mi implementación utilizando JumpServer.

El objetivo no es simplemente instalar otra aplicación. Quiero construir una capa centralizada de acceso para mi infraestructura Proxmox, Linux, Kubernetes y, posteriormente, bases de datos.

¿Qué es Privileged Access Management?

Privileged Access Management, normalmente conocido como PAM, es un enfoque de seguridad utilizado para controlar y monitorear el acceso a infraestructura sensible.

Las cuentas privilegiadas pueden incluir:

• cuentas root de Linux;

• usuarios con sudo;

• administradores de Proxmox;

• administradores de Kubernetes;

• administradores de bases de datos;

• administradores de dispositivos de red;

• cuentas utilizadas por servicios y automatizaciones.

Sin PAM, los administradores normalmente acceden directamente a la infraestructura:

1Administrador
2      |
3      | SSH
4      v
5Servidor Linux
6

O:

1Administrador
2      |
3      | kubeconfig
4      v
5Kubernetes API
6

Este modelo funciona, pero conforme crece la infraestructura comienzan los problemas.

Las llaves SSH terminan distribuidas en diferentes sistemas. Las credenciales de Kubernetes pueden encontrarse en las laptops de los administradores. Las cuentas privilegiadas compartidas dificultan las auditorías.

Además existe un problema fundamental:

Saber que alguien inició sesión no significa saber qué hizo después de autenticarse.

Una plataforma PAM introduce una capa controlada entre los usuarios y la infraestructura.

 1                    +------------------+
 2                    |   Administrador  |
 3                    +---------+--------+
 4                              |
 5                         MFA / SSO
 6                              |
 7                              v
 8                    +------------------+
 9                    | Plataforma PAM   |
10                    |    JumpServer    |
11                    +------------------+
12                      /       |       \
13                     /        |        \
14                    v         v         v
15              Linux/VMs   Kubernetes   Bases de datos
16                 SSH        MicroK8s
17

En lugar de permitir que los administradores se conecten directamente a cada sistema, el acceso puede pasar a través de la plataforma PAM.

Esto proporciona un punto central para autenticación, autorización, auditoría de sesiones y políticas de acceso.

¿Por qué implementar PAM en un homelab?

Inicialmente, implementar PAM en un homelab podría parecer excesivo.

Sin embargo, un laboratorio avanzado puede reproducir muchos de los mismos problemas de administración de accesos que existen en ambientes productivos.

Mi infraestructura utiliza Proxmox y múltiples sistemas MicroK8s para experimentar con tecnologías relacionadas con DevOps, SRE, bases de datos, Kubernetes y automatización de infraestructura.

Esto lo convierte en un excelente entorno para experimentar con prácticas como:

• Zero Trust;

• Role-Based Access Control;

• Multi-Factor Authentication;

• auditoría de sesiones privilegiadas;

• administración de credenciales;

• principio de mínimo privilegio;

• acceso Just-In-Time;

• acceso centralizado a infraestructura.

También resuelve un problema práctico.

No quiero que el acceso a mi infraestructura dependa de una colección de llaves SSH privadas distribuidas en diferentes computadoras.

Quiero acercarme a un modelo como:

 1Identidad
 2   |
 3   v
 4Autenticación + MFA
 5   |
 6   v
 7Política de autorización
 8   |
 9   v
10PAM Gateway
11   |
12   +------> Proxmox
13   |
14   +------> Linux VMs
15   |
16   +------> MicroK8s
17   |
18   +------> Bases de datos
19   |
20   +------> Dispositivos de red
21

Idealmente, cada conexión privilegiada debe estar asociada con una identidad, una autorización, una fecha, un recurso y un registro de auditoría.

Requerimientos para mi laboratorio PAM

Antes de seleccionar una plataforma definí algunos requerimientos.

La solución debería ser preferentemente:

Open source

Al tratarse de un laboratorio quiero poder desplegar, analizar, modificar, destruir y reconstruir la plataforma sin depender de licenciamientos costosos.

Self-hosted

El control plane de PAM debe ejecutarse dentro de infraestructura que yo controle.

Compatible con SSH

La mayoría de mi infraestructura Linux es administrada utilizando SSH.

Compatible con Kubernetes

MicroK8s representa una parte importante del laboratorio.

Compatible con bases de datos

Quiero extender posteriormente la arquitectura al acceso privilegiado a bases de datos.

Auditable

Poder determinar quién accedió a un servidor y qué ocurrió durante la sesión es una de las principales razones para implementar PAM.

Compatible con MFA

Una contraseña comprometida no debería proporcionar automáticamente acceso privilegiado a la infraestructura.

Compatible con RBAC

Los usuarios únicamente deberían poder visualizar y acceder a los recursos que están autorizados a administrar.

Compatible con automatización

Al ser un ambiente DevOps/SRE, la plataforma no debería impedir futuras integraciones con Infrastructure as Code y automatización.

¿Por qué no utilizar simplemente un Bastion Host?

Un bastion SSH tradicional ya representa una mejora importante.

 1Internet / VPN
 2      |
 3      v
 4+-------------+
 5| SSH Bastion |
 6+------+------+
 7       |
 8   +---+---+
 9   |       |
10   v       v
11Server A Server B
12

Las reglas del firewall pueden configurarse para permitir conexiones SSH únicamente desde el bastion.

Sin embargo, un bastion por sí solo no necesariamente representa un sistema PAM completo.

Todavía necesitamos responder:

• ¿Quién puede acceder a cada servidor?

• ¿Qué cuenta privilegiada puede utilizar?

• ¿Puede expirar automáticamente el acceso?

• ¿Se requiere MFA?

• ¿Podemos grabar las sesiones?

• ¿Podemos auditar los comandos?

• ¿Quién modificó una credencial privilegiada?

• ¿Podemos requerir aprobación antes de proporcionar acceso?

• ¿Podemos aplicar el mismo modelo a Kubernetes y bases de datos?

Aquí es donde una plataforma PAM comienza a ser mucho más interesante.

Alternativas Open Source a Teleport

Teleport probablemente sea una de las primeras plataformas que encontramos al investigar soluciones modernas para controlar el acceso a infraestructura.

Su arquitectura basada en certificados y su integración con SSH y Kubernetes la hacen particularmente interesante para ambientes cloud-native.

Sin embargo, quería explorar alternativas que ofrecieran una buena experiencia self-hosted y un modelo más amplio de PAM.

Entre los proyectos que considero interesantes se encuentran:

JumpServer

JumpServer es una plataforma open source de Privileged Access Management construida alrededor de cuatro áreas principales:

• autenticación;

• autorización;

• administración de cuentas;

• auditoría.

Soporta diferentes tipos de infraestructura y protocolos, incluyendo:

• SSH;

• RDP;

• VNC;

• Kubernetes;

• MySQL;

• PostgreSQL;

• SQL Server;

• Oracle;

• Redis;

• MongoDB;

• dispositivos de red;

• aplicaciones web.

Para mi infraestructura, la combinación de SSH + Kubernetes + bases de datos + auditoría de sesiones hace que JumpServer sea particularmente interesante.

Su Community Edition puede ser desplegada de forma self-hosted y utiliza licencia GPL-3.0.

Teleport

Teleport aborda el problema desde una perspectiva ligeramente diferente.

Es particularmente potente como plataforma de acceso a infraestructura basada en identidad y certificados de corta duración.

Su arquitectura funciona especialmente bien con:

• SSH;

• Kubernetes;

• bases de datos;

• aplicaciones web;

• infraestructura cloud-native.

Para organizaciones fuertemente orientadas hacia Kubernetes y accesos efímeros basados en identidad, Teleport continúa siendo una alternativa muy interesante.

Para este laboratorio, sin embargo, quiero experimentar con algo más cercano a un modelo tradicional y completo de PAM.

Warpgate

Warpgate es otro proyecto open source interesante.

Funciona como un bastion inteligente y está enfocado en proporcionar acceso controlado sin requerir agentes en cada servidor destino.

Su arquitectura relativamente ligera puede hacerlo especialmente atractivo para homelabs y ambientes pequeños.

Es una alternativa que vale la pena investigar cuando queremos evolucionar desde un bastion tradicional hacia autenticación y auditoría más avanzadas sin implementar una plataforma PAM de mayor tamaño.

Bastillion

Bastillion es una consola SSH web y una solución de bastion.

Permite centralizar el acceso SSH y la administración de llaves SSH.

Su alcance es menor que el de plataformas como JumpServer o Teleport, pero esa simplicidad puede representar una ventaja cuando el objetivo principal es administrar accesos a servidores Linux.

HashiCorp Boundary

Boundary utiliza un enfoque basado en identidad para proporcionar conectividad segura hacia infraestructura.

En lugar de distribuir credenciales y exponer directamente los endpoints de infraestructura, Boundary funciona como intermediario para establecer conexiones autorizadas.

Su arquitectura resulta especialmente interesante para infraestructura dinámica en ambientes cloud.

Sin embargo, su filosofía está más orientada hacia conectividad segura que hacia una plataforma PAM tradicional todo-en-uno.

JumpServer vs Teleport para mi laboratorio

La decisión no consiste realmente en determinar cuál producto es universalmente mejor.

Se trata de decidir qué arquitectura quiero experimentar.

Teleport sería una elección natural si mi principal objetivo fuera implementar acceso SSH y Kubernetes basado en certificados.

JumpServer resulta especialmente interesante porque quiero experimentar específicamente con PAM, incluyendo cuentas privilegiadas, administración de credenciales, grabación de sesiones, assets de infraestructura y auditoría centralizada.

Por esta razón, JumpServer será la primera plataforma que implementaré en el laboratorio.

Arquitectura PAM propuesta

Mi laboratorio actualmente está construido principalmente sobre Proxmox.

En lugar de instalar JumpServer directamente dentro de Kubernetes, inicialmente quiero mantener el control plane de PAM separado de la infraestructura que protege.

Conceptualmente:

 1                         USUARIOS
 2                            |
 3                      HTTPS / SSH
 4                            |
 5                            v
 6                 +----------------------+
 7                 |      JumpServer      |
 8                 |                      |
 9                 | Autenticación + MFA  |
10                 | RBAC / ACL           |
11                 | Credenciales         |
12                 | Auditoría            |
13                 +----------+-----------+
14                            |
15                    Management Network
16                            |
17       +--------------------+--------------------+
18       |                    |                    |
19       v                    v                    v
20+-------------+      +-------------+      +-------------+
21| Proxmox     |      | Linux VMs   |      | Databases   |
22| Hosts       |      | / Services  |      | MySQL/etc.  |
23+-------------+      +-------------+      +-------------+
24                            |
25                            v
26                   +------------------+
27                   | MicroK8s Cluster |
28                   +------------------+
29                     |      |      |
30                   Node1  Node2  Node3
31

JumpServer puede ejecutarse inicialmente dentro de una VM dedicada.

Esto crea una separación importante:

El sistema PAM no debería depender completamente de la misma infraestructura a la que debe proporcionar acceso durante una emergencia.

Colocar la única instancia PAM dentro del clúster Kubernetes que administra podría crear una dependencia circular durante una falla.

Para la primera iteración, una VM dedicada en Proxmox tiene más sentido.

Segmentación de red

PAM se vuelve mucho más efectivo cuando se combina con controles de red.

En lugar de:

1Laptop ----------SSH----------> Server
2

quiero llegar a:

 1Laptop
 2   |
 3   | HTTPS / SSH
 4   v
 5JumpServer
 6   |
 7   | SSH
 8   v
 9Server
10

Las reglas de firewall pueden posteriormente aplicar:

 1Administrator VLAN
 2       |
 3       +------> JumpServer
 4                    |
 5                    +------> Management VLAN
 6                                  |
 7                                  +--> Proxmox
 8                                  +--> Linux
 9                                  +--> MicroK8s
10                                  +--> Databases
11

Eventualmente podemos bloquear el acceso administrativo SSH directo hacia los sistemas administrados.

Únicamente JumpServer —además de un mecanismo controlado de emergencia— debería poder alcanzar las interfaces administrativas.

De esta forma PAM deja de ser simplemente otro portal de acceso y se convierte en una verdadera frontera de seguridad.

Un requerimiento crítico: Break-Glass Access

Existe una excepción importante.

La plataforma PAM no debe convertirse en un punto único de falla operacional.

Si JumpServer falla, necesito conservar un método cuidadosamente controlado para recuperar la infraestructura.

Es necesario mantener un mecanismo de break-glass access.

 1Acceso normal
 2
 3Administrador
 4     |
 5JumpServer
 6     |
 7Infraestructura
 8
 9
10Acceso de emergencia
11
12Administrador autorizado
13     |
14VPN / Management Network
15     |
16Credencial de emergencia
17     |
18Infraestructura
19

Las credenciales de emergencia deben estar fuertemente protegidas, utilizarse raramente y ser monitoreadas.

El objetivo no es eliminar completamente el acceso administrativo de emergencia.

El objetivo es convertirlo en una excepción y no en la forma normal de administrar la infraestructura.

Integrando MicroK8s

El acceso a Kubernetes resulta particularmente interesante porque los archivos kubeconfig pueden convertirse prácticamente en credenciales privilegiadas.

Un administrador puede tener:

1~/.kube/config
2

con credenciales capaces de administrar un clúster completo.

Desde el punto de vista de seguridad, esto convierte a la computadora del administrador en parte de la frontera de acceso privilegiado.

Una arquitectura PAM puede mejorar este modelo.

Para mis ambientes MicroK8s quiero probar:

1. registrar los clústeres Kubernetes en JumpServer;

2. mapear usuarios y permisos;

3. limitar acceso a clústeres específicos;

4. probar workflows con kubectl;

5. auditar sesiones Kubernetes;

6. implementar mínimo privilegio;

7. reducir kubeconfigs administrativos innecesarios en endpoints.

Esta será una de las partes más importantes del laboratorio.

Integrando Proxmox

Proxmox presenta otro escenario interesante.

Existen realmente dos superficies diferentes de acceso privilegiado.

La primera es la interfaz web/API de Proxmox.

La segunda es el sistema operativo Debian/Linux de cada nodo Proxmox.

Para la primera implementación, JumpServer puede proteger el acceso SSH hacia los hosts Proxmox.

Posteriormente quiero evaluar cómo integrar la autenticación y API de Proxmox sin crear dependencias innecesarias.

El modelo deseado es:

 1Administrador
 2      |
 3      v
 4Identidad / MFA
 5      |
 6      v
 7JumpServer
 8      |
 9      v
10Proxmox Management
11

en lugar de distribuir credenciales SSH de root entre diferentes equipos administrativos.

Las bases de datos serán el siguiente paso

Otra razón para seleccionar JumpServer es el acceso a bases de datos.

Los administradores frecuentemente requieren cuentas privilegiadas como:

1root
2postgres
3admin
4dba
5

Distribuir directamente estas credenciales dificulta mantener una trazabilidad adecuada.

Eventualmente quiero implementar:

1Engineer
2   |
3   v
4PAM
5   |
6   +----> MySQL
7   +----> PostgreSQL
8   +----> Redis
9

Esto será particularmente útil para experimentar con prácticas relacionadas con Database Reliability Engineering.

¿Qué quiero conseguir?

La arquitectura final debería permitirme responder preguntas que sorprendentemente son difíciles de contestar en muchas infraestructuras:

¿Quién accedió a este servidor?

¿Cuándo accedió?

¿Qué cuenta privilegiada utilizó?

¿Qué comandos fueron ejecutados?

¿Quién accedió al clúster Kubernetes?

¿Qué base de datos fue utilizada?

¿Puedo revocar el acceso de una persona sin rotar credenciales en todos mis servidores?

¿Puedo requerir MFA antes de proporcionar acceso privilegiado?

Si la plataforma puede responder consistentemente estas preguntas, entonces la implementación PAM está proporcionando valor real.

Roadmap de implementación

Construiré el laboratorio incrementalmente.

Fase 1 — Instalar JumpServer

Crear una VM dedicada en Proxmox e instalar JumpServer Community Edition.

Validar:

• HTTPS;

• acceso administrativo;

• backups;

• almacenamiento persistente;

• MFA.

Fase 2 — Linux

Registrar máquinas virtuales Linux y nodos Proxmox.

Configurar usuarios, cuentas privilegiadas, grupos de assets, RBAC y acceso SSH.

Fase 3 — Auditoría

Configurar y probar:

• grabación de sesiones;

• auditoría de comandos;

• logs de autenticación;

• auditoría de transferencia de archivos.

Posteriormente realizar intencionalmente diferentes operaciones administrativas y verificar qué información queda registrada.

Fase 4 — MicroK8s

Registrar los clústeres MicroK8s y probar acceso controlado a Kubernetes.

El objetivo será reducir la necesidad de kubeconfigs administrativos de larga duración.

Fase 5 — Bases de datos

Agregar ambientes MySQL, PostgreSQL y Redis y experimentar con acceso privilegiado.

Fase 6 — Controles de red

Cuando PAM funcione correctamente, modificar progresivamente las políticas de firewall para que las interfaces administrativas sean accesibles principalmente mediante JumpServer.

Fase 7 — Break Glass

Documentar y probar el procedimiento de acceso de emergencia.

Un procedimiento de recuperación que nunca ha sido probado realmente no es un procedimiento de recuperación.

PAM es más que instalar JumpServer

Una conclusión es clara incluso antes de comenzar la instalación:

Instalar un producto PAM no significa automáticamente tener una arquitectura PAM.

El software es solamente uno de los componentes.

Una implementación adecuada también necesita:

 1Identidad
 2   +
 3MFA
 4   +
 5RBAC
 6   +
 7Administración de credenciales
 8   +
 9Segmentación de red
10   +
11Auditoría de sesiones
12   +
13Logging
14   +
15Break-Glass Access
16   +
17Procedimientos operacionales
18

Sin estos controles, JumpServer simplemente se convertiría en un jump box más sofisticado.

El verdadero objetivo es conseguir que el acceso privilegiado sea intencional, identificable, limitado, auditable y revocable.

Conclusión

Conforme un homelab evoluciona hacia un ambiente de infraestructura más serio, su arquitectura de seguridad también debe evolucionar.

Mi ambiente Proxmox y MicroK8s ha llegado al punto donde administrar todos los accesos únicamente mediante llaves SSH, kubeconfigs y cuentas privilegiadas ya no es el modelo que quiero utilizar.

Implementar PAM proporciona una oportunidad para mejorar esta arquitectura mientras experimento con patrones de seguridad utilizados en ambientes empresariales.

Después de evaluar diferentes enfoques open source, decidí comenzar utilizando JumpServer debido a que combina capacidades tradicionales de PAM con soporte para la infraestructura que más me interesa: Linux, Kubernetes, bases de datos y ambientes heterogéneos.

El siguiente paso es donde comienza la parte realmente interesante.

En el próximo artículo construiré la VM de JumpServer en Proxmox, instalaré la Community Edition, configuraré HTTPS y MFA y agregaré los primeros servidores Linux.

Posteriormente avanzaremos progresivamente hacia un ambiente Proxmox y MicroK8s controlado mediante PAM.

El objetivo no es simplemente construir un jump server.

El objetivo es construir una arquitectura de acceso privilegiado.