 |
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 este artículo te mostraremos todo lo relativo a la gestión de usuarios y permisos en Checkmk. Pero antes de entrar en detalles, primero tenemos que aclarar algunos términos.
En Checkmk, un usuario es alguien que tiene acceso a la interfaz de usuario. Un usuario tiene uno o varios roles ,que son la base de los permisos.
En cuanto un usuario es responsable de determinados host y servicios, se le identifica como contacto. Normalmente, un contacto sólo ve sus propios host y servicios en el entorno de monitorización, y se le puede notificar cualquier problema con ellos.
También hay usuarios que no son contactos. Un ejemplo de ello es cmkadmin, que se genera automáticamente cuando se crea un site. Este usuario puede ver todos los host y servicios, pero sólo porque el rol admin contiene el permiso See all hosts and services, y no necesariamente porque sea un contacto para todo.
Si se ha creado un contacto con el único fin de notificar (por ejemplo, para reenviar notificaciones a un sistema de tickets), puede ser útil crearlo de forma que no sea posible el inicio de sesión en la interfaz.
Un contacto siempre es miembro de uno o varios grupos de contacto. La finalidad de estos grupos es asignar contactos a hosts y servicios. Por ejemplo, el contacto hhirsch podría estar en el grupo de contacto linux y éste, a su vez, podría asignarse a todos los hosts Linux mediante una regla. Una asignación directa de contactos a hosts o servicios no es posible y, de hecho, podría crear dificultades en la práctica (por ejemplo, cuando un usuario abandona la organización).
En resumen:
Los usuarios pueden utilizar la interfaz de usuario.
Loscontactos son usuarios responsables de host y servicios concretos.
Los grupos de contacto definen de qué es responsable un usuario.
Los roles definen qué permisos tiene un usuario.
2. Gestión de usuarios a través del entorno de configuración
2.1. Vista general
La página de gestión de usuarios se encuentra en Setup > Users > Users. En un site recién creado, esta página tiene el siguiente aspecto (sólo acortado por unas pocas columnas de tabla en la imagen):
La imagen anterior muestra todos los usuarios que se crearon automáticamente al crear el site. Se trata en primer lugar de dos usuarios de automatización, seguidos del usuario único (cmkadmin) para el inicio de sesión interactivo con contraseña. Con el appliance Checkmk, este usuario puede tener un nombre diferente, ya que tú mismo defines su nombre y contraseña. Este usuario cmkadmin tiene las siguientes propiedades:
Este usuario tiene el rol Administrator (
admin) y, por tanto, todos los permisos.No es responsable de ningún contacto y no recibe ninguna notificación.
Sin embargo, pueden verlo todo (debido a su rol
admin).Definitivamente, ¡deberías cambiar la contraseña que se asignó cuando se creó el site!
El formulario para crear un nuevo usuario se abre con - o para editar un usuario existente con , está dividido en cinco secciones. La primera sección se refiere a la identidad:
2.2. Identidad
Como siempre en Checkmk, la identidad de un conjunto de datos (Username en este caso) no se puede cambiar posteriormente. Se utiliza para iniciar sesión y también como clave interna en todos los archivos y estructuras de datos.
La dirección de correo electrónico es opcional y sólo es necesaria si el usuario va a convertirse en un contacto al que se va a notificar por correo electrónico(configuración SMTP). Asimismo, el campoPager address está pensado para notificaciones a través de SMS o sistemas similares. Si escribes tus propios script de notificación, puedes acceder a los valores de estos campos y utilizarlos para cualquier fin.
Con Authorized sites puedes restringir opcionalmente a cuáles de los sitios existentes se puede acceder. Esto es especialmente práctico para entornos muy grandes, como una monitorización distribuida con cientos de sitios. Si un usuario sólo necesita un cierto número de estos sitios para sus host, la GUI sólo contactará con los sitios autorizados para configurar las vistas, lo que a su vez mejora mucho el rendimiento.
2.3. Seguridad
La segunda caja es para el registro y la autorización. La opción Automation secret for machine accounts está pensada para cuentas que acceden a Checkmk a través de HTTP y se autentifican a través de la URL. A continuación te mostraremos cómo hacerlo.
Para los roles, debes seleccionar al menos uno. En teoría, podrías asignar a un usuario varios roles, y así obtendría los derechos de todos ellos. Sin embargo, con los roles predefinidos (ver más abajo), esto tendría poco sentido.
Si bloqueas usuarios con la opción disable the login to this account, aparecerán en la tabla con el icono . Ya no podrán iniciar sesión, pero seguirán en el sistema. Si un usuario es un contacto, las notificaciones no se verán afectadas y el usuario seguirá recibiendo correos electrónicos, etc. Si el usuario estaba conectado en el momento del bloqueo, se desconectará automáticamente.
2.4. Grupos de contacto
En cuanto asignes un usuario a uno o varios grupos de contacto, este usuario se convierte en contacto. Cuando se crea un nuevo site, también se crea el grupo de contacto Everything, que siempre contiene todos los host y todos los servicios. Un usuario de este grupo será automáticamente responsable de todos los hosts y servicios.
2.5. Notificaciones
En la caja Notifications, puedes utilizar la opción Receive fallback notifications para especificar que este contacto recibirá notificaciones cuando no se aplique ninguna regla de notificación.
2.6. Configuración personal
Los usuarios también pueden cambiar ellos mismos todos los ajustes de esta caja a través de User > Edit profile (excepto con el rol guest ). Aparte de la selección del idioma de la interfaz, estos ajustes rara vez son necesarios. Puedes encontrar más detalles, como siempre, en la ayuda en línea.
2.7. Configuración de la interfaz
Los usuarios también pueden personalizar los ajustes de la interfaz por sí mismos mediante User > Edit profile. De particular interés es la opción Show more / Show less para determinar si Checkmk debe mostrar más o menos en la interfaz. Si siempre quieres verlo todo, puedes forzarlo aquí con Enforce show more.
3. Grupos de contacto
3.1. Creación y edición de grupos de contacto
Los grupos de contacto son el vínculo entre los host y servicios, por un lado, y los contactos, por otro. Cada grupo de contacto representa una responsabilidad para un área específica de tu entorno informático. Por ejemplo, el grupo de contacto "SAP" podría incluir a todas las personas que mantienen sistemas SAP y asignarse a todos los host y servicios que prestan dichos servicios en este entorno.
Gestionas los grupos de contacto a través de Setup > Users > Contact groups. La siguiente figura muestra este módulo con cuatro grupos de contacto creados:
Crear un nuevo grupo es trivial. Como siempre, el ID es permanente y el alias es un nombre para mostrar que puedes cambiar después en cualquier momento:
El nuevo grupo de contacto está vacío en dos aspectos: no contiene ni contactos ni host ni servicios. La asignación de grupos de contacto a los contactos se realiza a través de los perfiles de usuario, como ya has visto al editar el usuario.
Configurar la visibilidad del inventario
Además, puedes configurar la visibilidad del inventario que se encuentra con el Inventario de hardware/software. Por defecto, todo el inventario está visible, pero también se puede suprimir por completo o activar selectivamente con la opción Allowed to see the following entries y las rutas de inventario internas:
A continuación, puedes utilizar esta información para rellenar las rutas y los atributos para hacer visibles, por ejemplo, sólo algunos datos seleccionados del inventario del procesador (modelo y arquitectura):
3.2. Añadir hosts a un grupo de contacto
Existen dos métodos para incluir hosts en grupos de contacto: mediante carpetas y mediante reglas. También puedes combinar ambos métodos. En este ejemplo, se asignará al host una agregación de los respectivos grupos de contacto.
Asignación mediante carpetas
Puedes acceder a las propiedades de una carpeta a través de Folder > Properties mientras estás en la carpeta. Allí encontrarás la opción Permissions. Activa este checkbox para acceder a la selección de grupos de contacto:
El verdadero objetivo de esta opción es establecer permisos para el mantenimiento de host, que explicamos en detalle más adelante.
En cuanto hayas asignado permisos para grupos de contacto específicos, puedes a su vez introducir estos grupos como grupos de contacto para los hosts en la monitorización. Al hacerlo, puedes decidir si las asignaciones deben aplicarse también a los hosts de las subcarpetas y si los servicios de estos hosts también deben recibir explícitamente estos grupos. Los servicios sin asignaciones explícitas heredan todos los grupos de contacto de un host, incluso los asignados por reglas.
 |
La herencia del atributo Permissions sobre las carpetas se anula en este punto. Esto te permite añadir más grupos de contacto a las subcarpetas. Por tanto, la asignación también se realiza de forma acumulativa a través de todas las carpetas padre, si en estas carpetas padre se ha activado la opción Add these groups as contacts in all subfolders. |
Por cierto, también puedes encontrar las opciones de grupo de contacto de forma simplificada directamente en los detalles de un host, lo que significa que también puedes utilizarlas para asignar grupos de contacto a host individuales. Sin embargo, como esto puede volverse rápidamente bastante confuso, sólo deberías hacerlo en casos excepcionales y, si es necesario, tal vez prefieras trabajar con reglas.
Asignación mediante reglas
El segundo método -asignar grupos de contacto mediante reglas-es un poco más engorroso, pero mucho más flexible. Y resulta muy útil si no has configurado tu estructura de carpetas según principios organizativos estructurados y, por tanto, no puedes asignar claramente carpetas a grupos de contacto.
El conjunto de reglas Assignment of hosts to contact groups necesario para ello se encuentra enSetup > Hosts > Host monitoring rules. En este conjunto de reglas, encontrarás una regla predefinida que se generó cuando se creó el site, y que asigna todos los host al grupo de contacto Everything.
Ten en cuenta que este conjunto de reglas está definido de forma que se evalúen todas las reglas aplicables, ¡y no sólo la primera! Puede ser útil que un host pertenezca a más de un grupo de contacto. En tal caso, necesitarás un conjunto de reglas para cada asignación.
3.3. Incluir servicios en los grupos de contacto
No siempre tiene sentido que un servicio esté en los mismos grupos de contacto que su host. Por eso, puedes utilizar el conjunto de reglas Assignment of services to contact groups, independientemente de los grupos de contacto del host. Se aplican las siguientes reglas:
Si a un servicio no se le asigna un grupo de contacto, recibe automáticamente los mismos grupos de contacto que su host.
En cuanto se asigna explícitamente al menos un grupo de contacto a un servicio, éste deja de heredar los grupos de contacto del host.
Por tanto, en un entorno sencillo, basta con que sólo asignes grupos de contacto a los host. En cuanto necesites más diferenciación, también puedes crear reglas para los servicios.
3.4. Controlar las asignaciones
Puedes comprobar si has configurado correctamente todas las reglas y carpetas consultando los detalles de un host o servicio en el entorno de monitorización. Allí encontrarás las entradas Host contact groups y Host contacts (o Service contact groups y Service contacts respectivamente), que enumeran las asignaciones reales de este objeto:
4. Visibilidad de host y servicios
4.1. Vista general
El hecho de que los usuarios normales (el rol user ) sólo vean los objetos de los que son contacto es tanto más importante cuanto mayor sea tu entorno de monitorización. Esto no sólo proporciona una visión general despejada, sino que también evita que los usuarios intervengan donde no les corresponde.
Como administrador (el rol admin ) siempre tienes permiso para verlo todo. Esto se controla mediante el permiso See all host and services. En tu configuración personal encontrarás en Visibility of hosts/services la checkbox Only show hosts and services the user is a contact for. Con ella puedes renunciar voluntariamente a verlo todo y mostrar sólo los host y servicios de los que eres contacto. Esta opción está pensada para roles duales, es decir, para alguien que es a la vez administrador y usuario normal.
El rol guest está preconfigurado para que sus usuarios también puedan verlo todo. La intervención o los ajustes personales están desactivados aquí.
Para los usuarios normales, la visibilidad en el entorno de monitorización está implementada de tal forma que los host y servicios de los que no eres contacto ni siquiera parecen existir en el sistema. Entre otras cosas, los siguientes elementos tienen en cuenta la visibilidad:
Vistas de hosts y servicios
Vista general snap-in de la barra lateral
Informes creados por el usuario
4.2. Visibilidad de los servicios
Como hemos visto antes, puede ocurrir que seas contacto de un host, pero no de todos sus servicios. No obstante, en ese caso podrás ver todos los servicios del host en la GUI.
Esta excepción se establece por defecto porque suele ser útil. En la práctica, esto significa, por ejemplo, que el colega responsable del host real también puede ver todos los servicios que están conectados a ese host -¡sin embargo, no recibe ninguna notificación de los servicios!
Si no te gusta este enfoque, puedes cambiarlo a través de Global settings > Monitoring Core > Authorization settings. Si allí cambias la configuración de Hosts a Strict - Visible if user is contact for the service, los usuarios sólo podrán ver los servicios si han sido asignados directamente como contacto para el servicio.
Por cierto, todo esto no tiene nada que ver con el hecho de que un servicio herede los grupos de contacto de su host si no se le han asignado grupos de contacto propios, ya que entonces tú serías un contacto para el servicio, y por tanto recibirías sus notificaciones.
4.3. Grupos del host y del servicio
La segunda opción de la página global Authorization settings se refiere a los grupos del host y de servicio. Normalmente puedes ver un grupo siempre que puedas ver al menos un elemento del grupo, sin embargo, el grupo se verá entonces como si sólo contuviera los elementos que son visibles para ti.
Si seleccionas Strict - Visible if all members are visible, se ocultarán todos los grupos de los que no seas contacto para al menos un host o servicio.
Ten en cuenta que estos dos ajustes de visibilidad no influyen en las notificaciones.
5. Notificaciones
Las asignaciones de contactos también influyen en las notificaciones. Checkmk está preconfigurado para que todos los contactos del host o servicio afectado reciban una notificación en caso de problema. Esto se hace mediante una regla de notificación que se genera automáticamente cuando se crean nuevos sites. Se trata de una función muy sensata.
No obstante, si es necesario, puedes adaptar la regla o complementarla con otras reglas, de modo que en casos extremos las notificaciones puedan realizarse de forma totalmente independiente de los grupos de contacto. Una razón común para ello es que un usuario desee no recibir determinadas notificaciones, o viceversa, que se le informe sobre problemas con hosts o servicios individuales, aunque no sea directamente responsable de ellos (y, por tanto, no sea un contacto explícito).
Para más detalles, consulta el artículo sobre notificaciones.
6. Funciones y permisos
6.1. Roles predefinidos
Checkmk siempre asigna permisos a los usuarios mediante roles, nunca directamente. Un rol no es más que una lista de permisos. Es importante que entiendas que los roles definen el nivel de permisos y no una referencia a ningún host o servicio. Para eso están los grupos de contacto.
Checkmk viene con los siguientes roles predefinidos, que nunca se pueden eliminar, pero que se pueden personalizar como se desee:
| Rol | Permisos | Función |
|---|---|---|
|
Todos los permisos, especialmente el derecho a cambiar permisos. |
El administrador de Checkmk que mantiene el propio sistema de monitorización. |
|
Sólo puede ver sus propios host y servicios, sólo puede hacer cambios en la interfaz web en carpetas compartidas para ellos y, en general, no puede hacer nada que afecte a otros usuarios. |
El usuario normal de Checkmk, que utiliza la monitorización y reacciona a las notificaciones. |
|
El permiso para registrar el agente Checkmk de un host con el servidor Checkmk para la transmisión de datos encriptados por TLS, nada más. |
Este rol se asigna al usuario de automatización |
|
Puede verlo todo pero no cambiar nada. |
Invitado está pensado simplemente para 'mirar', para lo cual todos los invitados comparten una cuenta común. También es útil para monitorizaciones de estado "públicas" colgadas en una pared. |
Los roles se gestionan a través de Setup > Users > Roles & permissions:
Por cierto, al crear un nuevo site Checkmk, sólo se crea un usuario (cmkadmin) para el rol admin. Los otros roles posibles no se utilizarán por el momento. Si necesitas un usuario invitado, deberás crearlo tú mismo.
6.2. Personalizar roles existentes
Como de costumbre, el te lleva al modo de edición de un rol:
Puedes averiguar qué significan los distintos permisos (mostrados aquí en extractos) en la ayuda en línea.
La particularidad aquí es que para cada permiso hay tres opciones:sí, no y por defecto ( sí) o por defecto (no). En el momento de la instalación, todos los valores se establecen por defecto. Para la autorización en sí no hay ninguna diferencia entre haber establecido sí o por defecto (sí). Sin embargo, es posible que la instalación de una nueva versión de Checkmk pueda cambiar un valor por defecto (aunque esto ocurra muy raramente). En ese caso, una configuración que hayas establecido explícitamente no se vería afectada por la instalación.
Además, este principio te permite reconocer muy rápidamente dónde puede haberse desviado de la norma tu instalación de Checkmk.
6.3. Definir roles propios
Puede que te sorprenda que no haya ningún botón para crear un nuevo rol. ¡Hay una razón deliberada para ello! Los nuevos roles se crean derivándolos de roles existentes mediante Clone. El nuevo rol no se crea simplemente como una copia, sino que mantiene su relación con el rol original Based on role:
Esta conexión tiene una función importante, ya que todos los permisos del rol clonado que no estén definidos explícitamente (es decir, que sigan definidos en default) se heredarán del rol de origen. Los cambios posteriores en el rol de origen se trasladarán al nuevo rol clonado. Esto es muy práctico si tienes en cuenta la cantidad de permisos que puede haber en el rol original. Con una simple copia, podrías perder fácilmente la noción de lo que realmente tiene de especial el rol que has definido para ti.
Esta función de derivación también resuelve otro problema: como seguimos desarrollando Checkmk, continuamente se añaden nuevos permisos. Cada vez decidimos entonces en cuál de los tres roles, admin, user y guest debe tener el nuevo permiso.
Como cada uno de tus propios roles se deriva de uno de los tres roles predefinidos, el nuevo permiso se preestablece automáticamente en un valor razonable. Sería muy poco práctico que, por ejemplo, definieras tu propio rol user y siempre faltaran allí nuevos permisos. Tendrías que adaptar tu rol a cada nueva función para que tus usuarios pudieran utilizarlas.
6.4. Comparar roles con la vista de tabla
Si quieres comparar los permisos de los roles individuales, puedes ayudarte de la vista de matriz, accesible a través de Setup > Users > Roles & permissions > Permission matrix.. Esta opción de menú crea la siguiente vista, en la que no sólo puedes comparar los permisos de los roles individuales, sino también ver dónde se han establecido () o eliminado () permisos explícitamente.
7. Configuración personal
Cada usuario puede gestionar un pequeño número de ajustes de usuario para su propio perfil. En el artículo sobre lainterfaz de usuario encontrarás una descripción detallada de todas las opciones disponibles.
Una nota adicional para la monitorización distribuida: En un entorno de monitorización distribuida, cualquier nueva configuración se transfiere inmediatamente a todos los sites de monitorización. Sin embargo, esto sólo funciona para los sites que son accesibles a través de la red en ese momento. Todos los demás sites reciben las actualizaciones en la siguiente activación correcta de cambios.
8. Usuario de automatización (para servicios web)
Cuando se conecta Checkmk a otros sistemas, a menudo se desea automatizar ciertas actividades que normalmente tienen lugar a través de la GUI. Algunos ejemplos son:
Establecer y eliminar tiempos de mantenimiento programados mediante un script
Administración de host mediante API-REST
Recuperar datos de vistas de tabla en formatos CSV o JSON para su posterior proceso
Recuperar el estado actual de las Agregaciones BI para crearlas como servicio
En estas situaciones, el software externo debe ser capaz de recuperar determinadas URL de la interfaz de Checkmk de forma automática. Esto, por supuesto, plantea la cuestión de cómo se conecta el usuario. La forma habitual a través del diálogo de inicio de sesión es engorrosa y requiere la recuperación de varias URL en sucesión y el almacenamiento de una cookie.
Para simplificarlo, Checkmk ofrece el concepto de usuarios de automatización. Estos usuarios son exclusivamente para el control remoto y no permiten un inicio de sesión normal a través de la GUI. La autenticación se realiza aquí a través de la autenticación básica HTTP.
En cada site Checkmk ya hay configurados dos usuarios de automatización: para los servicios web y para el registro del agente en el servidor Checkmk para la transferencia de datos encriptada por TLS. Puedes utilizar estos usuarios de automatización o crear uno nuevo. Se crea un usuario de automatización como un usuario normal, pero no se le asigna una contraseña normal, sino una contraseña de automatización (Automation secret). Puedes hacer que se cree automáticamente con el cubo:
Un usuario de automatización tiene un rol igual que un usuario normal y también puede ser un contacto. Esto significa que puedes restringir los permisos y la visibilidad de los host y servicios según sea necesario.
Para la recuperación automática de páginas web, introduce la cabecera de la autenticación básica HTTP, que básicamente tiene este aspecto: Authorization: Basic 1234567890abcdef. La cadena de caracteres es la forma codificada en Base64 de username:password.
Aquí tienes un ejemplo de recuperación de una vista en formato JSON con el usuario de automatización automation y la contraseña de automatización de la imagen anterior - la codificación Base64 se realiza mediante curl:
root@linux# curl --user automation:a8075a39-e7fe-4b5c-9daa-02635 'http://moni01.mycompany.net/mysite/check_mk/view.py?view_name=svcproblems&output_format=json'
[
"service_state",
"host",
"service_description",
"service_icons",
"svc_plugin_output",
"svc_state_age",
"svc_check_age",
"perfometer"
],
[
"CRIT",
"stable",
"Filesystem /",
"menu pnp",
"CRIT - 96.0% used (207.27 of 215.81 GB), (warn/crit at 80.00/90.00%), trend: +217.07 MB / 24 hours",
"119 min",
"30 sec",
"96%"
],
...Si el script que recupera la URL se ejecuta directamente en el site de monitorización, puedes leer la contraseña de automatización del usuario directamente del sistema de archivos. Esto no es una vulnerabilidad de seguridad, pero pretende serlo: puedes escribir scripts de automatización que no necesiten contener la contraseña de automatización y no necesiten un archivo de configuración. Para ello, lee el archivo ~/var/check_mk/web/myuser/automation.secret:
OMD[mysite]:~$ cat var/check_mk/web/automation/automation.secret
a8075a39-e7fe-4b5c-9daa-02635Puedes almacenar fácilmente el contenido de este archivo en una variable del shell:
OMD[mysite]:~$ SECRET=$(cat var/check_mk/web/automation/automation.secret)
OMD[mysite]:~$ echo "$SECRET"
a8075a39-e7fe-4b5c-9daa-02635También lo utiliza, por ejemplo, el script downtime, que encontrarás en el directorio Checkmk treasures, que puedes utilizar para establecer y eliminar tiempos de inactividad programados controlados por script para hosts y servicios. Si el usuario de automatización se llama automation, como en nuestro ejemplo, el único argumento que necesitarás es el nombre del host para el que quieras especificar un tiempo de inactividad programado:
OMD[mysite]:~$ ~/share/doc/check_mk/treasures/downtime.py myhost123Puedes encontrar más opciones para este script en su ayuda en línea:
OMD[mysite]:~$ ~/share/doc/check_mk/treasures/downtime.py --help9. Inicio de sesión automático a través de la URL
|
El inicio de sesión automático a través de la URL en el navegador que se describe a continuación está desactivado por motivos de seguridad desde Checkmk 2.2.0, porque las credenciales (nombre de usuario y contraseña) que se pasan a través de la URL se almacenan en los archivos de registro del Apache específico del site (ver Werk #14261). Si quieres utilizar el inicio de sesión automático a través de la URL a pesar de este riesgo de seguridad, debes activarlo explícitamente con la configuración global Setup > General > Global settings > User interface > Enable login via GET requests. |
Como hemos visto, puedes utilizar usuarios de automatización para recuperar cualquier URL mediante un script, sin necesidad de iniciar sesión. Sin embargo, en situaciones que requieren un inicio de sesión real en el navegador, esto no funciona, porque no se transmiten los datos de inicio de sesión de los enlaces incluidos (por ejemplo, a imágenes e iframes).
El mejor ejemplo de esto es el deseo de colgar en una pared un monitor que muestre continuamente un dashboard específico de Checkmk. Este monitor debe ser controlado por un ordenador que abra automáticamente el navegador al iniciarse, inicie sesión en Checkmk y llame al dashboard requerido.
Para conseguirlo, lo mejor es crear primero un usuario especial para este fin. El rol guest es muy adecuado para esta función porque concede todos los derechos de lectura, pero no permite ningún cambio ni intervención.
Construye la URL para un inicio de sesión automático como sigue:
Empieza por:
http://mycmkserver/mysite/check_mk/login.py?_origtarget=Determina la URL real que se mostrará (por ejemplo, la del dashboard) con tu navegador -preferiblemente sin navegación-, lo que puede hacerse a través de Display > This page without navigation.
Añade esta URL, omitiendo todo lo que hay antes de la parte
/mysite/….Añade a la URL las dos variables
_usernamey_passwordde la siguiente forma:&_username=myuser&_password=mysecret.Añade otro
&_login=1.
Aquí tienes un ejemplo de URL:
http://mycmkserver/mysite/check_mk/login.py?_origtarget=/mysite/check_mk/dashboard.py?name=mydashboard&_username=myuser&_password=mypassword&_login=1Nota:
En el ejemplo, sustituye los valores
mycmkserver,mysite,myuserymypasswordpor tus valores apropiados. No puedes utilizar el usuario de automatización comomyuser, ya que el inicio de sesión a través de la GUI no está permitido para este usuario.Si los caracteres especiales
&o%aparecen en uno de estos valores o en el valor de_origtarget, debes sustituirlos de la siguiente manera:&por%26y%por%25.
Pruébalo todo cerrando la sesión de tu navegador desde Checkmk y copiando la URL construida en tu navegador. A continuación, debes ir directamente a la página de destino, sin diálogo de inicio de sesión. Al mismo tiempo, estarás conectado y podrás llamar directamente a los enlaces contenidos en la página.
También puedes probar la URL terminada con curl en la línea de comando. Si lo has hecho todo correctamente, recibirás el código de estado HTTP 302 FOUND y serás redirigido a la página location especificada, como en la siguiente salida abreviada:
OMD[mysite]:~$ curl -v 'http://mycmkserver/mysite/check_mk/login.py?_origtarget=/mysite/check_mk/dashboard.py?name=mydashboard&_username=myuser&_password=mypassword&_login=1'
...
< HTTP/1.1 302 FOUND
...
< Location: /mysite/check_mk/dashboard.py?name=mydashboard
...Si no obtienes la vista de tabla deseada en el navegador a pesar de este mensaje de confirmación de éxito, comprueba la URL indicada en Location- aunque sea incorrecta, curl devolverá el código de estado HTTP 302 FOUND.
Si los datos de inicio de sesión son incorrectos, recibirás el código de estado HTTP 200 OK, pero sólo verás el código HTML de la página de inicio de sesión, como en la siguiente salida abreviada:
OMD[mysite]:~$ curl -v 'http://mycmkserver/mysite/check_mk/login.py?_origtarget=/mysite/check_mk/dashboard.py?name=mydashboard&_username=myuser&_password=NOT&_login=1'
...
< HTTP/1.1 200 OK
...
<!DOCTYPE HTML>
<html><head><meta content="text/html; ...
...
</script>
<script type="text/javascript">
cmk.visibility_detection.initialize();
</script>
</body></html>10. Permisos en Checkmk
10.1. Función del rol "usuario" en Checkmk
Si tienes que gestionar un entorno de monitorización algo mayor, entonces querrás implicar a otros administradores en la configuración y, sobre todo, en la gestión de host y servicios. Para que mantengas el control sobre quién tiene permiso para hacer cambios y qué se le permite hacer, y para que la gente no se estorbe entre sí, puedes asignar permisos para la Configuración de Checkmk basándote en carpetas.
El primer paso para ello es hacer que tus colegas administradores trabajen con sus propios usuarios basándose en el rol user.
Este rol tiene básicamente autorización para el entorno de configuración, pero con algunas restricciones importantes:
Sólo se permiten cambios en host, servicios, reglas y Agregaciones BI.
Los host, servicios y reglas sólo pueden gestionarse en carpetas compartidas.
Las Agregaciones BI sólo pueden gestionarse en paquetes BI compartidos.
Todo lo que tenga implicaciones globales no está permitido.
Mientras no hayas liberado todavía ninguna carpeta o paquete BI, esto significa que los usuarios con el rol user no pueden realizar inicialmente ningún cambio. El sencillo menú Setup de la barra de navegación tiene el siguiente aspecto para los usuarios normales:
10.2. Permitir a los usuarios la administración del host
Un usuario recibe autorización para crear, editar y eliminar hosts a través de grupos de contacto.El procedimiento es el siguiente:
Añade al usuario a un grupo de contacto.
Designa una o varias carpetas para las que el usuario debe estar autorizado.
Activa la propiedad Permissions para estas carpetas y selecciona aquí el grupo de contacto.
El siguiente ejemplo muestra las propiedades de una carpeta en la que todos los usuarios del grupo de contacto Linux están autorizados a administrar host. Se ha activado la opción para permitirlo también en las subcarpetas.
Si quieres incluir automáticamente los hosts en el grupo de contacto es cosa tuya. En este ejemplo no se ha activado la opción Add these groups as contacts to all hosts in this foldery los hosts no se añadirán al grupo de contacto Linux. Esto significa que en el entorno de monitorización no serán visibles para el grupo de contacto Linux (a menos que una regla se encargue de ello). Así que, como puedes ver, la visibilidad (y la responsabilidad en la monitorización) y la autorización para el entorno de configuración pueden regularse por separado.
11. Contraseñas
11.1. Seguridad de las contraseñas
Hoy en día, la seguridad es una gran prioridad. Por eso, en algunas empresas existen directrices generales sobre cómo tratar las contraseñas. Checkmk ofrece varias opciones de configuración para aplicarlas. Algunas de ellas se encuentran en Global settings > User management > Password policy for local accounts:
La primera opción Minimum password length es para garantizar la calidad de la contraseña.
Para la segunda opción Number of character groups to use hay un total de cuatro grupos de caracteres:
letras minúsculas
letras mayúsculas
dígitos
caracteres especiales
Si introduces aquí un 4, la contraseña debe contener al menos un carácter de cada uno de los grupos anteriores. Con un 2 se garantiza al menos que la contraseña no esté formada, por ejemplo, sólo por letras minúsculas. Esta configuración se comprueba cada vez que se cambia la contraseña.
La tercera opción Maximum age of passwords obliga al usuario a cambiar su contraseña a intervalos regulares. Una vez llegado el momento, el siguiente acceso a la página presentará al usuario el siguiente aviso:
Los usuarios sólo podrán continuar después de cambiar su contraseña.
Puedes exigir el cambio de la contraseña inicial en el primer inicio de sesión. Esto se hace con la opción Enforce change: Change password at next login or access en la sección Security de las propiedades del usuario correspondiente.
11.2. Directivas de inicio de sesión
En Global settings > User management encontrarás más opciones globales que regulan el inicio de sesión de los usuarios.
Bloqueo tras inicios de sesión inválidos
Con la opción Lock user accounts after N logon failures, puedes bloquear una cuenta tras una serie de intentos fallidos de inicio de sesión:
En ese caso, sólo podrá desbloquearla un usuario con el rol admin. Como administrador, puedes desbloquear a otros usuarios a través de Setup > Users >Users y, a continuación, de las propiedades del usuario bloqueado. Ten en cuenta que las cuentas de administrador también pueden bloquearse! Si estás permanentemente bloqueado como último o único administrador, sólo podrás desbloquear tu cuenta a través de la línea de comandos. Para ello, edita el archivo etc/htpasswd como usuario del site y elimina el signo de exclamación de la línea del usuario afectado, aquí myuser:
OMD[mysite]:~$ cat etc/htpasswd
agent_registration:$2y$12$83XzYwtQJVFizC...
automation:$2y$12$zKF4Sasws7rDJCByZ1r5ke...
cmkadmin:$2y$12$ZmE96frGSm9sdWiWRXtxbuyu...
myuser:!$2y$12$8FU93yH7TFTyJsyUvKCh1eqYJG..
OMD[mysite]:~$ vim etc/htpasswd
...
OMD[mysite]:~$ cat etc/htpasswd
agent_registration:$2y$12$83XzYwtQJVFizC...
automation:$2y$12$zKF4Sasws7rDJCByZ1r5ke...
cmkadmin:$2y$12$ZmE96frGSm9sdWiWRXtxbuyu...
myuser:$2y$12$8FU93yH7TFTyJsyUvKCh1eqYJG...
Entonces podrás volver a iniciar sesión.
Cierre de sesión automático
En la caja Session management, puedes especificar dos formas distintas de finalizar una sesión y combinarlas entre sí: por un lado en función de la duración de la sesión, por otro en función de la actividad del usuario.
Maximum session duration garantiza que la sesión finalice automáticamente tras un periodo de tiempo determinado. Entre otras cosas, esto reduce el riesgo de uso externo de la sesión, ya que no permanece activa indefinidamente:
Una vez expirada la duración definida de la sesión, el usuario debe volver a conectarse, independientemente de si estaba activo o no al final de la sesión. Al mismo tiempo, puedes utilizar Advise re-authentication before termination para especificar cuándo se debe avisar al usuario para que guarde sus entradas, cierre la sesión y vuelva a conectarse antes de una finalización "dura" de su sesión:
El ajuste Set an individual idle timeout garantiza que la sesión finalice si el usuario no utiliza activamente la GUI durante un periodo de tiempo prolongado. Por ejemplo, si ha abandonado temporalmente su puesto de trabajo sin cerrar la sesión en Checkmk. Este timeout puede detenerse utilizando activamente la GUI. Sin embargo, no basta con tener abierta una vista que se recargue periódicamente.
Impedir el inicio de sesión múltiple
La opción Limit login to single session at a time impide que un usuario inicie sesión en Checkmk con dos navegadores al mismo tiempo:
Esta opción también está vinculada a un timeout para un cierre de sesión automático en caso de inactividad. Esta función también tiene sentido. Supongamos que te has olvidado de cerrar la sesión en tu puesto de trabajo antes de cerrar el navegador. En esta situación, sin un timeout, no podrías iniciar sesión desde casa mientras estás de guardia, ¡ya que cerrar el navegador o apagar el ordenador no desencadena automáticamente un cierre de sesión!
Al intentar un segundo inicio de sesión en paralelo, verás el siguiente mensaje de error:
En este caso, el inicio de sesión sólo puede llevarse a cabo si finalizas activamente la sesión existente o esperas a que expire el timeout.
11.3. Autenticación de dos factores
Para mejorar la seguridad de tus sites de Checkmk, Checkmk proporciona la función de autenticación de dos factores para cada usuario. Esta autenticación de dos factores se basa en el estándar de internet FIDO2/WebAuthn. Convencionalmente, la autenticación se basa en el conocimiento (una contraseña) y la posesión (un autenticador). Puedes utilizar cualquier hardware compatible con FIDO2 que admitan tu navegador y tu sistema operativo. Los tokens USB o NFC, como el YubiKey, son los más utilizados. Como alternativa, es posible utilizar autenticadores de software (aplicaciones de autenticación en el smartphone) que generan una contraseña de un solo uso basada en el tiempo (TOTP).
Requisitos del servidor Checkmk
Debido a las especificaciones del estándar WebAuthn, hay tres requisitos previos para el uso de la autenticación de dos factores:
Especificación de la dirección web como un simple nombre del host o como un nombre de dominio completo, en cualquier caso una dirección de dominio válida.
La URL se introduce siempre en el mismo formato, por ejemplo, siempre
https://www.mycompany.com/mysite.
Configurar
Accede a la autenticación de dos factores desde el menú Usuario.
Ahora se te darán dos opciones marcadas con el icono de la llave para añadir el segundo factor:Register authenticator app para configurar una app que genere contraseñas de un solo uso, y Register security token para utilizar un token de hardware.
Checkmk reconoce las opciones de autenticación disponibles en tu ordenador. Se abrirá un pequeño diálogo en la ventana del navegador en el que deberás especificar el autenticador. Si utilizas un token de hardware, la configuración se completará cuando toques el botón. Si utilizas contraseñas de un solo uso, deberás introducir una contraseña generada para la confirmación. La sesión continuará sin problemas en ambos casos.
Inicio de sesión
La autenticación de dos factores estará activa en Checkmk para futuros intentos de inicio de sesión: Primero, introduce tu nombre de usuario y contraseña como de costumbre. A continuación, aparecerá otra pantalla de inicio de sesión:
Tras activar el autentificador, podrás trabajar con Checkmk como de costumbre.
Crear y utilizar códigos de copia de seguridad
En caso de que no tengas tu autenticador a mano, puedes introducir un código de seguridad.
Para ello, crea de antemano una lista de códigos de seguridad en la página User > Two-factor authentication utilizando Generate backup codes.
Guarda estos códigos en un lugar seguro.
Si luego quieres iniciar sesión con un código de copia de seguridad en el sitio web de Checkmk con un código de copia de seguridad, haz clic en Use backup code en la segunda pantalla de inicio de sesión. Introduce uno de tus códigos de copia de seguridad e inicia sesión con Use backup code.
Comprobar y anular la autenticación de dos factores como administrador
Como administrador, en la gestión de usuarios (Setup > Users > Users) puedes ver qué usuarios han tenido una autenticación de dos factores configurada mirando la entrada en la columna Authentication.
Si uno de estos usuarios ya no tiene acceso a Checkmk -por ejemplo, si ha perdido o dañado su token de hardware- puedes eliminar la autenticación de doble factor para este usuario. Para ello, abre la entrada correspondiente en la gestión de usuarios haciendo clic en . En la vista de usuario, elimina la autenticación de doble factor para este usuario a través de User > Remove two-factor authentication.
Tras tu confirmación del aviso de seguridad, el usuario podrá volver a iniciar sesión en la interfaz web de Checkmk utilizando "sólo" el nombre de usuario y la contraseña.
11.4. Cambiar una contraseña utilizando la línea de comandos
En caso de emergencia, también puedes cambiar una contraseña a través de la línea de comandos. Esto te salva en una situación en la que hayas perdido la contraseña de cmkadmin. El requisito previo es, por supuesto, que aún sea posible iniciar sesión como usuario de Linux en el servidor Checkmk y que puedas convertirte en usuario del site con omd su mysite.
Las contraseñas se almacenan en el archivo ~/etc/htpasswd, como ya se ha descrito anteriormente.
El cambio de contraseñas se realiza con el comando cmk-passwd. Éste no te pedirá la contraseña existente.cmk-passwd elegirá siempre un método de encriptación seguro para almacenar tus contraseñas en una versión actual de Checkmk. Actualmente cmk-passwd utiliza bcrypt para ello. Las contraseñas no encriptadas o débilmente encriptadas (por ejemplo, con MD5) no permiten el inicio de sesión en la GUI.
OMD[mysite]:~$ cmk-passwd cmkadmin
New password: secret
Re-type new password: secret12. Atributos de usuario personalizados
Además del campo para la dirección de correo electrónico, también está disponible el campo Pager address para notificar a los usuarios. Si esto no es suficiente y quieres almacenar más información sobre un usuario, puedes crear tus propios campos a través de Setup > Users > Custom user attributes > Add attribute, que luego se pueden rellenar con valores individuales para cada usuario.
Al crear un nuevo atributo de este tipo, se abre el siguiente diálogo:
Como siempre, el ID (Name) no puede cambiarse posteriormente, pero el título (Title) sí. Topic determina en qué sección de la configuración de usuario se ordenará el nuevo campo. Además, puedes decidir si los usuarios pueden editar el campo ellos mismos (entonces aparecerá en su configuración personal) y si el valor debe mostrarse directamente en la tabla de usuarios.
|
Sólo si activas el checkbox en Make this variable available in notifications podrás utilizar también este valor en las notificaciones. Para ello, el valor debe asignarse al núcleo de monitorización (por ejemplo, CMC) en una variable (una denominada "macro definida por el usuario"). |
El nombre de la variable personalizada se deriva del ID que hayas elegido. Éste se convierte en mayúsculas y se prefija con un CONTACT_. Un phone se convierte entonces en CONTACT_PHONE. Ten en cuenta que cuando la variable se pasa a través de variables del entorno, la variable se prefijará con NOTIFY_. Con tu propio script de notificación, la variable llegará como NOTIFY_CONTACT_PHONE.
13. Escribir mensajes a los usuarios
En el artículo que describe las notificaciones, entramos en gran detalle sobre cómo Checkmk puede informar a los contactos sobre problemas con host o servicios. Sin embargo, a veces puede que quieras notificar a todos los usuarios (incluso a los que no son contactos) asuntos internos de la organización, por ejemplo, el mantenimiento del propio sistema Checkmk.
Para tales fines, Checkmk ofrece una pequeña herramienta de mensajes integrada, que es completamente independiente de las notificaciones. Puedes encontrar la herramienta a través de Setup > Users y allí en Users > Send user messages. Aquí tienes la posibilidad de enviar un mensaje a todos o a algunos de tus usuarios.
Puedes elegir entre cuatro tipos de mensajes:
Show popup message |
La próxima vez que el usuario abra la página, se abrirá una ventana emergente con el mensaje. |
Show hint in the 'User' menu |
Al usuario se le indica el mensaje mediante un símbolo numérico en el menú Usuario de la barra de navegación. |
Send email |
Envía un correo electrónico. Sin embargo, esto sólo llegará a los usuarios que también tengan configurada una dirección de correo electrónico. |
Show in the dashboard element 'User messages' |
El mensaje se muestra en un dashlet del tipo User messages. |
Con Message expiration puedes eliminar fácilmente los mensajes que aún no se hayan recuperado en cuanto dejen de ser relevantes.
14. Otros temas
Checkmk admite más métodos de conexión:
Conexión de un LDAP/Directorio Activo
Autenticación con SAML
Autenticación con Kerberos
Autenticación en una configuración con proxy inverso
Autenticación con autenticación básica HTTP
15. Archivos y directorios
La siguiente lista muestra qué archivos y directorios del servidor Checkmk están relacionados con la gestión de usuarios. Como siempre, todas las entradas aquí son relativas al directorio del site (por ejemplo, /omd/sites/mysite).
| Ruta | Función |
|---|---|
|
Contraseñas de usuarios en formato Apache |
|
Este archivo contiene un secreto aleatorio que se utiliza para firmar las cookies de inicio de sesión. En entornos distribuidos, este archivo debería ser el mismo para todos los sites -y así será si lo configuras todo con la interfaz web-. Si se modifica este archivo, todos los inicios de sesión se invalidan inmediatamente y los usuarios deben volver a iniciar sesión. Este archivo es privilegiado |
|
Números de serie de las contraseñas por usuario. Cualquier cambio de contraseña incrementa el número de serie y, por tanto, invalida todas las sesiones en curso. Esto garantiza que un cambio de contraseña cierra la sesión de un usuario de forma fiable. |
|
Contiene los usuarios configurados con el entorno de configuración. Aquí sólo se almacenan los datos de los usuarios que se ocupan exclusivamente de la GUI. Los cambios manuales en este archivo surten efecto inmediatamente. |
|
Información de contacto de los usuarios configurados con el entorno de configuración. Aquí se almacenan todos los datos relevantes para la configuración del núcleo de monitorización. Sólo se enumeran aquí los usuarios que también son contactos. Para que los cambios manuales surtan efecto aquí, la nueva configuración debe cargarse en el núcleo, por ejemplo, con |
|
Cada usuario que se haya conectado a la GUI al menos una vez tiene una subcarpeta aquí donde se almacenan cosas como vistas e informes personalizados, la configuración actual de la barra lateral y mucho más, en pequeños archivos individuales con la extensión |
|
Archivo de registro de la interfaz de usuario. Aquí encontrarás mensajes de error relativos a la autenticación y a las conexiones LDAP. |