Administración de Usuarios en Nagios
A menudo, son múltiples los usuarios en una organización quieren tener acceso a Nagios. Para hacer frente a los diferentes requisitos que podemos encontrarnos en las empresas podemos usar varios enfoques. En este post se analiza brevemente cada técnica para ayudarnos a decidir qué funcionará mejor para nuestra organización.
Un administrador y una cuenta RO compartida
Este escenario es común en las organizaciones que se iniciaron en Nagios siendo pequeñas y están creciendo, o para entornos de empresas de desarrollo, donde el control de acceso granular no es crítico.
En este modo, el administrador de Nagios sólo tiene que definir una cuenta en el archivo de configuración CGI con derechos de administrador y una segunda cuenta con acceso de sólo lectura. La cuenta de sólo lectura puede o no tener la capacidad de realizar acciones basadas en GUI, como volver a enviar los chequeos de servicios, acusar recibo de problemas de servicio o de host, o deshabilitar las notificaciones. Si un administrador decide permitir estas acciones dependerá de las políticas locales de seguridad y del nivel de confianza que tiene con sus usuarios.
Un administrador y múltiples cuentas RO
En las organizaciones en las que Nagios se implementa en entornos de producción, o el número de usuarios que chequean de forma activa Nagios es mayor, o si hay grupos de usuarios que necesitan acceso a grupos específicos de chequeos este escenario funciona bien. Las cuentas de solo lectura podrían ser cuentas compartidas utilizadas por grupos de personas. Las cuentas incluso podría asignarse a grupos de correo electrónico.
Por ejemplo, si una organización tiene un alias de correo electrónico windows_admins, el administrador puede crear un usuario Nagios llamado windows_admins. El usuario windows_admins usaría la dirección de correo windows_admins y la cuenta tendría acceso limitado a sólo los servidores de Windows en la red de la organización, haciendo uso de los controles de acceso de grano fino en el archivo de configuración de Nagios CGI.
Múltiples administradores, múltiples cuentas semiprivilegiadas y una cuenta RO
En este escenario podría usarse un marco de single-sign-on usando LDAP para centralizar el acceso. Aunque Nagios no soporta directamente LDAP, pueden usarse una serie de módulos LDAP para Apache para autenticar a los usuarios, incluyendo mod_authnz_ldap.
El problema de usar LDAP directamente de esta manera es que para cada usuario LDAP, tendrían que añadirse entradas al archivo de configuración CGI para dar permisos al usuario que se extiendan más allá de los roles concedidos al usuario por defecto.
Por esta razón, se recomienda que un administrador configure un script que se ejecute cada noche para consultar y escribir el archivo de configuración CGI para cada usuario. Los roles deseados se pueden mantener en una base de datos u otro almacén de archivos, y el script puede crear todas las configuraciones de usuario y el archivo de configuración principal de CGI para dar los permisos de grano fino necesarios para una gran organización.
Alta de un usuario en Nagios
Los usuarios en Nagios se deben dar de alta en el archivo “/opt/nagios/etc/htpasswd.users”, luego se crea una entrada en “/opt/nagios/etc/contacts.cfg” y se añade al grupo pertinente.
Entramos en el servidor de Nagios y ejecutamos el comando htpasswd sobre el fichero “/opt/nagios/etc/htpasswd.users” con el usuario que queremos añadir (aquí como ejemplo está pgomez):
# cd /opt/nagios/etc
# htpasswd htpasswd.users pgomez
New password: ******
Re-type new password: ******
Adding password for user pgomez
Editamos el archivo de “/opt/nagios/etc/objects/contacts.cfg” y añadimos la entrada de contact para “pgomez”:
define contact{
contact_name pgomez
use generic-contact
alias Pedro Gomez
email pedro.gomez@dominio.com
}
Añadimos el nuevo contacto al grupo de contactos que corresponda:
define contactgroup{
contactgroup_name admins
alias Nagios Administrators
members nagiosadmin,pgomez
}
Para cambiar la contraseña de un usuario solo tenemos que ejecutar el primer punto.
Configurar un usuario para ver Hosts y Servicios específicos
Creamos la definición del contacto para el cliente:
define contact{
contact_name customer1
alias Customer One Admin
service_notification_period 24x7
host_notification_period 24x7
service_notification_options c,r
host_notification_options d,r
service_notification_commands notify-service-by-email
host_notification_commands notify-host-by-email
email customer1@domain.tld
}
Creamos un grupo de contactos o añadimos el nuevo contacto a un grupo ya existente, dependiendo de los chequeos que queramos permitir:
define contactgroup {
contactgroup_name Dedicated-Server1-Admins
alias Admins for Server 1
members customer1,hostingadmins
}
Usamos el nuevo grupo con los correos de los clientes y nuestro administrador principal:
define host {
use generic-host
host_name Server1
alias Server1
address 10.0.0.2 // private or public ip
hostgroups DedicateServers
check_command check-host-alive
contact_groups Dedicated-Server1-Admins
check_period 24x7
max_check_attempts 10
notification_interval 480
notification_period 24x7
notification_options d,r
notifications_enabled 1
}
define service {
use generic-service
host_name Server1
service_description HTTP
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 3
contact_groups Dedicated-Server1-Admins
notification_interval 480
notification_period 24x7
notification_options w,u,c,r
check_command check_http
notifications_enabled 1
}
En este caso hemos creado un nuevo grupo y hemos añadido los contactos y clientes.
Por último añadimos el usuario htaccess a nuestro archivo htpasswd (htpasswd.users). El nombre de usuario debe coincidir con el contacto. En este ejemplo es customer1.
Tras esto, reiniciamos Nagios.