Configurar el acceso SSH con grabación de sesiones y servidores bastión en contenedores: parte 1

Con la gran mayoría de las personas trabajando desde casa en estos días, el acceso remoto a los sistemas se está convirtiendo en la norma. La administración y configuración segura de servidores de forma remota es extremadamente crítica para la continuidad del negocio.

La mayoría de los administradores confían en SSH (con o sin VPN) para la administración remota. Siempre ha habido una demanda de la capacidad de grabar sesiones de usuario/administrador por motivos de seguridad y responsabilidad, así como para compartir conocimientos.

Esta serie de artículos cubre las capacidades listas para usar de Red Hat Enterprise Linux (RHEL) 8.2 (contenedores sin raíz con Podman, grupos de control v2, systemd, ssh, tlog, y Gestión de identidad RHEL) para implementar una solución que ayude a los administradores a brindar acceso seguro a los usuarios. Pueden configurar la grabación de sesiones para algunos o todos los usuarios, así como la autenticación centralizada (incluida la autenticación de dos factores) y la autorización (HBAC, sudo centralizado) para servidores back-end (destino).

Índice

    ¿Por qué SSH en contenedores para servidores bastión?

    Los contenedores generalmente se consideran adecuados para cargas de trabajo sin estado y el servidor SSH no es una carga de trabajo común para los contenedores. Sin embargo, en el pasado ha habido algunas solicitudes al equipo de soporte de Red Hat para brindarle consejos sobre cómo configurarlo.

    Algunos de los beneficios asociados con este enfoque son:

    • Ejecute varios contenedores SSH en la misma VM para hacer un mejor uso de los recursos.
    • Ofrezca diferentes perfiles de SSH y QoS a grupos de usuarios específicos.
    • Aprovisione/reconstruya nuevos contenedores de servidores SSH a pedido, ya sea por razones de seguridad (por ejemplo, un nuevo conjunto de servidores todos los días), disponibilidad (impacto limitado, superficie de ataque más pequeña) o escalabilidad (un aumento repentino en la cantidad de usuarios que necesitan acceso) por razones .
    • Configure el acceso de tiempo limitado a los servicios para conjuntos específicos de usuarios.
    • Registre y mantenga de forma centralizada las sesiones de usuario y los registros de acceso SSH utilizando volúmenes persistentes sin tener que realizar cambios en los servidores back-end.
    • Marco de autenticación de varias capas para SSH con mecanismos de autenticación y autorización independientes para servidores bastión y back-end.

    Grabación de sesión

    RHEL 8 introdujo la posibilidad de grabar sesiones usando tlog. Se puede configurar en todo el sistema para todos los usuarios o se puede limitar a usuarios específicos. Esta capacidad se puede utilizar en los contenedores del servidor bastión para capturar y registrar todas las acciones del usuario en el contenedor y cualquier servidor posterior al que acceda el usuario a través del servidor SSH en contenedor.

    ¿Por qué contenedores sin raíz?

    Los contenedores sin raíz son una característica nueva en RHEL 8. Con la Disponibilidad general de cgroups v2 en RHEL 8.2, algunos de los limitaciones previas asociados con contenedores sin raíz han sido mitigados. Ejecutar contenedores sin privilegios de root mejora la seguridad. En el caso de un contenedor comprometido, el atacante puede tener menos acceso al host y el contenedor comprometido se reemplaza fácilmente o se actualizan sus credenciales. Con cgroups v2, los contenedores también son usar systemd para iniciar/detener servicios en contenedores sin root (anteriormente esto solo funcionaba con contenedores ejecutándose como root).

    Usar systemd ofrece otra ventaja: los administradores pueden capturar de forma centralizada todos los registros (acceso SSH y sesiones de usuario) en el contenedor a través de journald. Estos registros se pueden conservar asignando un volumen persistente (/var/log/journal) desde el host y también se puede enviar a una ubicación central (servidor de archivos o Búsqueda elástica) para su posterior análisis. Los registros de grabación de sesiones se pueden mantener en una ubicación central durante el tiempo que se desee, y cualquier sesión de usuario se puede reproducir a pedido.

    Mapeo de usuarios y control de acceso basado en host con IDM

    Red Hat IDM, basado en el proyecto freeIPA, está disponible de forma gratuita para todos los clientes de Red Hat Enterprise Linux. Admite funciones como autenticación centralizada y administración de acceso, control de acceso basado en host, integración de AD y autenticación de dos factores. Esto controla qué usuarios/grupos pueden conectarse a qué servidores/grupos de servidores y qué acciones pueden realizar usando sudo, todo ello desde un plan de gestión centralizado.

    Al agregar este control de acceso como una capa adicional detrás de los servidores bastión en contenedores, los administradores no solo pueden controlar qué acciones pueden realizar los usuarios en un conjunto designado de servidores, sino que también pueden tener un registro de auditoría completo con sesiones de usuario registradas.

    Arquitectura de alto nivel

    El siguiente diagrama ilustra una propuesta de arquitectura de alto nivel como punto de partida para esta solución. Este diseño se puede mejorar aún más con componentes adicionales, como servidores de archivos centralizados, Red Hat Satellite para la administración de parches y Ansible Tower para la automatización de la operación del día 2 y la delegación de tareas.

    Una configuración mínima requiere al menos dos servidores RHEL 8.2, uno para cada uno que sirva como servidor bastión y servidor IDM. Además, se requieren uno o más gabinetes RHEL (6, 7, 8) como servidores primarios (administrado u operado por el entorno de destino).

    Preparación del host (servidor bastión)

    Dado que no hay una imagen predefinida disponible para el servidor SSH en contenedores, crearemos una usando un archivo Docker personalizado. Para crear la imagen, se requiere un servidor RHEL 8.2 con el podman paquete instalado y cgroups v2 habilitado para usar systemd con contenedores sin raíz.

    Los siguientes pasos destacan este proceso:

    1. Verifique el sistema operativo y las versiones de Podman:

    # cat /etc/redhat-release
    
    # yum install -y podman slirp4netns Contenedores-common
    
    # podman version

    2. Habilite v2 cgroups en el servidor RHEL agregando el systemd.unified_cgroup_hierarchy=1 en la línea de comando de inicio y reinicie el servidor, por ejemplo:

    # grub2-editenv - set "kernelopts=root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap systemd.unified_cgroup_hierarchy=1"

    3. Después de reiniciar, confirme para usar cgroup v2:

    # findmnt -R /sys/fs/cgroup/
    
    TARGET SOURCE
    
    FSTYPE OPTIONS
    
    /sys/fs/cgroup cgroup2 cgroup2 rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate

    4. Establecer el container_manage_cgroup Boolean SELinux para permitir systemd para trabajar correctamente en un contenedor:

    # setsebool -P container_manage_cgroup on

    5. Aumentar el número de espacios de nombres de usuario:

    # echo "user.max_user_namespaces=28633" > /etc/sysctl.d/userns.conf
    
    # sysctl -p /etc/sysctl.d/userns.conf

    6. Cree un nuevo usuario en el servidor y defina el enable-linger opción para esto:

    # useradd test2; id -u test2
    
    # passwd test2
    
    # loginctl enable-linger `id -u test2`

    7. Verifique que el almacenamiento del contenedor esté en el sistema de archivos local. Actualmente, los sistemas de archivos remotos no funcionan bien con espacios de nombres de usuario sin privilegios. En este caso, /home/test2 debe estar en un sistema de archivos local:

    # podman info | grep GraphRoot
    
    GraphRoot: /home/test2/.local/share/Contenedores/Almacenamiento

    8. Inicie sesión en el registro de Red Hat con sus credenciales. Esto debería tener éxito:

    # podman login https://registry.redhat.io -u <username> -p <password>
    
    # podman pull registry.redhat.io/ubi8/ubi-init 

    Conclusión

    En esta parte de la serie, analizamos las razones para configurar el entorno de contenedor sin raíz. También analizamos la arquitectura, los requisitos de la versión y las tecnologías generales. En la siguiente parte de la serie, preparamos el archivo Docker para el servidor SSH en contenedor y probamos el contenedor que lo usa.

    Artículos de interés

    Subir