 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introducción
En las ediciones comerciales de Checkmk
puedes configurar los paquetes de agentes para que puedan ejecutarse en el host por un usuario sin privilegios, es decir, no por root.
Esta función está totalmente disponible inicialmente para los agentes de Linux que se hayan instalado como paquetes DEB o RPM.
El requisito previo para la ejecución sin privilegios es que el paquete del agente se haya instalado en un único directorio. La opción de seleccionar un directorio de instalación está disponible para Linux, así como para Solaris y AIX.
Las dos reglas relacionadas «Installation paths for agent files (Linux, UNIX)» y «Run agent as non-root user (Linux)» han quedado obsoletas. Está previsto eliminarlas en una futura versión de Checkmk.
 |
La funcionalidad que se presenta aquí es una vista previa técnica, es decir, un avance de una nueva característica que estará sujeta a desarrollo y ampliación hasta nuevo aviso. Durante esta fase, es posible que no solo se añadan funciones, sino que también se modifiquen de tal manera que las configuraciones existentes queden obsoletas y tengas que volver a crearlas. Te pedimos tu comprensión al respecto. |
2. Configuración de los paquetes de agentes
Los paquetes del agente se configuran en Agent Bakery, al que puedes acceder a través de Setup > Agents > Windows, Linux, Solaris, AIX. Haz clic en el botón «Agent rules». En «Agent rules > Linux/UNIX agent options» encontrarás la regla «Customize agent package (Linux)».
2.1. Especificar el directorio de instalación
Con Directory for Checkmk agent puedes especificar el directorio de instalación:
Todos los archivos del paquete del agente se instalan en este directorio en lugar de en directorios como /etc/, /usr/lib/ o /var/lib/.
Por motivos de seguridad, no selecciones ningún directorio dentro del directorio de inicio de un usuario.
En Solaris y AIX ya has terminado. En Linux, también puedes especificar la ejecución sin privilegios.
2.2. Configuración de la ejecución sin privilegios
Hay dos opciones básicas disponibles para el agente de Linux tras seleccionar «Customize user»:
Los valores predeterminados «Run agent as root, set agent controller user» y «cmk-agent» como usuario especifican exactamente el comportamiento predeterminado del agente de Checkmk para Linux, incluso sin configurar esta regla,
de modo que el controlador del agente se ejecutará como «cmk-agent» y el script del agente como «root».
Sin embargo, la novedad es la opción de especificar un usuario diferente como «cmk-agent».
La segunda opción es Run agent as non-root, set agent user. Esto especifica que, además del controlador del agente, el script del agente también se ejecutará bajo el usuario especificado, es decir, ambos carecen de privilegios.
También puedes asignar ID numéricos al usuario (UID) y al grupo (GID). Ten en cuenta las convenciones de tu distribución de Linux y cualquier limitación existente de los sistemas de archivos utilizados.
La última opción determina si el usuario seleccionado en esta regla debe crearse si aún no existe.
2.3. Preparación de la ejecución con privilegios de complementos de agente individuales
Para los complementos de agente, la regla Plug-ins, local checks and MRPE for non-root users te permite especificar individualmente los usuarios ejecutantes para directorios específicos. Esto te permite ejecutar complementos en carpetas específicas con otros ID de usuario sin privilegios o como root. Esta regla genera una configuración de agente que se instala automáticamente. A continuación describimos la configuración adicional en el host.
3. Configuración de la ejecución sin privilegios en el host
Si has configurado paquetes de agente para la ejecución sin privilegios, es posible que se requiera una configuración adicional en el host Linux en el que está instalado el paquete.
Por motivos de seguridad, un agente configurado para la ejecución sin privilegios ofrece un abanico de funciones ligeramente más reducido que un agente ejecutado con permisos de root. Para disponer de las funciones que faltan, tú, como administrador, debes encontrar métodos que sean eficaces y compatibles con las directrices de seguridad de tu organización y con las convenciones de la distribución de Linux utilizada.
|
Ten en cuenta que este capítulo no ofrece una solución única óptima ni para la configuración suministrada con los paquetes del agente ni para la configuración realizada en el host. Todas las soluciones posibles y sensatas deben basarse en las distribuciones utilizadas, las directrices operativas de tu organización y la facilidad de mantenimiento. |
3.1. Configuración desudo
Hemos añadido una función envolventa para el script del agente, que antepone «sudo» a los comandos que suelen requerir privilegios de alto nivel.
Esto afecta en Checkmk a 2.4.0, mdadm (para leer el estado de varios RAID de software y unidades cifradas), mailq (para leer la cola de correo del MTA Postfix) y a los scripts para supervisar sitios de Checkmk.
Puedes encontrar ejemplos de configuraciones para sudo en el directorio de instalación del agente, dentro de la subcarpeta default/package/agent/checkmk_agent_sudoers_template.
Puedes copiar las líneas necesarias a tu /etc/sudoers o copiar todo el archivo a /etc/sudoers.d (no recomendado).
Ajusta las entradas según corresponda.
Por ejemplo, en algunos casos no se necesitan permisos de superusuario para leer la cola de correo electrónico y se puede usar el ID de usuario con el que se ejecuta el MTA.
3.2. Ejecución de complementos de agente sin privilegios de root
Para la ejecución de complementos de agente, te recomendamos garantizar el acceso a la información necesaria mediante permisos de archivo, asignaciones de grupos o listas de control de acceso. La siguiente lista muestra los métodos posibles:
Añade al usuario bajo cuyo ID se ejecuta el script del agente a un grupo que pueda leer los datos necesarios en la supervisión.
Cambia los derechos de acceso o la asignación de grupo de los archivos del dispositivo (por ejemplo, mediante reglas de
udev) para que el usuario sin privilegios pueda acceder a ellos.
3.3. Ejecución de complementos de agente con privilegios de root
Si un complemento de agente requiere privilegios de root para ejecutarse, tienes las siguientes opciones:
Si es necesario, ejecuta los complementos mediante una tarea cron y redirige su salida a un archivo de spool. Con intervalos de más de un minuto entre ejecuciones, también cubres los complementos que, de otro modo, requerirían una ejecución asíncrona.
Si ya has empaquetado paquetes de agente con la regla «Plug-ins, local checks and MRPE for non-root users», entonces debes mover los complementos que deban ejecutarse como root a los directorios configurados y aplicar la configuración de «
sudo».
4. Instalación tradicional
La ejecución sin privilegios también es posible sin un controlador de agente o si la instalación no se puede realizar mediante un paquete DEB o RPM.
4.1. Instalación sin gestor de paquetes
Si utilizas los paquetes TGZ proporcionados en formato .tar.gz, debes asegurarte de que los permisos se conceden correctamente tras la instalación.
Utiliza como guía una instalación de ejemplo que hayas realizado en Linux con gestión de paquetes.
|
Iremos añadiendo más información a esta sección poco a poco. |
4.2. Ejecución sin el controlador de agente
Si no se puede o no se debe utilizar el controlador de agente, es posible tanto la llamada sin cifrar a través de (x)inetd como la llamada cifrada a través de Secure Shell.
Se requieren modificaciones menores en comparación con la llamada con permisos de root.
Xinetd
Si el controlador de agentes está desactivado o es incompatible, se activa el archivo de configuración para xinetd que se encuentra en el directorio de instalación en default/package/config/xinetd-service-template.cfg.
Este archivo ya contiene el usuario sin privilegios especificado por la regla del agente.
Si utilizas un super-servidor de Internet diferente (por ejemplo, el inetd de OpenBSD), crea la configuración según su documentación.
Puedes encontrar ejemplos en el artículo «Monitorización de Linux en modo heredado».
Secure Shell
La llamada a través de SSH también se corresponde con el procedimiento descrito en el artículo «Monitorización de Linux en modo heredado».
Solo hay que adaptar la ruta al archivo de configuración .ssh/authorized_keys y el nombre de usuario utilizado al usuario sin privilegios que estés utilizando.