 |
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. Introduction
Dans les éditions commerciales de Checkmk,
vous pouvez configurer les paquets d'agents de manière à ce qu'ils puissent être exécutés sur l'hôte par un utilisateur sans privilèges, c'est-à-dire non pas par l'utilisateuroot.
Cette fonctionnalité est initialement pleinement disponible pour les agents Linux, qui ont été installés sous forme de paquets DEB ou RPM.
La condition préalable à l'exécution sans privilèges est que le paquet d'agent ait été installé dans un seul répertoire. L'option permettant de sélectionner un répertoire d'installation est disponible pour Linux, ainsi que pour Solaris et AIX.
Les deux règles associées « Installation paths for agent files (Linux, UNIX) » et « Run agent as non-root user (Linux) » ont été dépréciées. Il est prévu de les supprimer toutes les deux dans une future version de Checkmk.
 |
La fonctionnalité présentée ici est une préversion technique, c'est-à-dire un aperçu d'une nouvelle fonctionnalité qui fera l'objet de développements et d'extensions jusqu'à nouvel ordre. Au cours de cette phase, il est possible que des fonctionnalités soient non seulement ajoutées, mais également modifiées de telle sorte que les configurations existantes deviennent obsolètes et que vous deviez les recréer. Nous vous remercions de votre compréhension à cet égard. |
2. Configuration des paquets d'agents
Les paquets d'agents sont configurés dans l'Agent Bakery, que vous pouvez ouvrir via Setup > Agents > Windows, Linux, Solaris, AIX. Cliquez sur le bouton «Agent rules». Sous «Agent rules > Linux/UNIX agent options», vous trouverez la règle «Customize agent package (Linux)».
2.1. Spécification du répertoire d'installation
Avec Directory for Checkmk agent, vous pouvez spécifier le répertoire d'installation :
Tous les fichiers du package de l’agent sont installés dans ce répertoire plutôt que dans des répertoires tels que /etc/, /usr/lib/ ou /var/lib/.
Pour des raisons de sécurité, ne sélectionnez aucun répertoire situé dans le répertoire personnel d’un utilisateur.
Pour Solaris et AIX, vous avez terminé. Pour Linux, vous pouvez également spécifier une exécution sans privilèges.
2.2. Configuration de l'exécution sans privilèges
Deux options de base sont disponibles pour l'agent Linux après avoir sélectionné « Customize user » :
Les valeurs par défaut « Run agent as root, set agent controller user » et « cmk-agent as user » définissent exactement le comportement par défaut de l’agent Checkmk pour Linux, même sans configurer cette règle,
de sorte que l’Agent Controller sera exécuté sous « cmk-agent » et le script de l’agent sous « root ».
La nouveauté réside toutefois dans la possibilité de spécifier un utilisateur différent comme « cmk-agent ».
La deuxième option est Run agent as non-root, set agent user. Cela spécifie qu’en plus de l’Agent Controller, le script de l’agent sera également exécuté sous l’utilisateur spécifié — c’est-à-dire que les deux sont sans privilèges.
Vous pouvez également attribuer des identifiants numériques à l'utilisateur (UID) et au groupe (GID). Veuillez tenir compte des conventions de votre distribution Linux et des éventuelles limitations des systèmes de fichiers utilisés.
La dernière option détermine si l'utilisateur sélectionné dans cette règle doit être créé s'il n'existe pas encore.
2.3. Préparation de l'exécution avec privilèges des plug-ins d'agent individuels
Pour les plug-ins d'agent, la règle Plug-ins, local checks and MRPE for non-root users vous permet de spécifier individuellement les utilisateurs chargés de l'exécution pour des répertoires spécifiques. Cela vous permet d'exécuter des plug-ins dans des dossiers spécifiques sous d'autres identifiants d'utilisateurs non privilégiés ou en tant que root. Cette règle génère une configuration d'agent qui est installée automatiquement. Nous décrivons ci-dessous la configuration supplémentaire sur l'hôte.
3. Configuration de l'exécution sans privilèges sur l'hôte
Si vous avez configuré des paquets d'agent pour une exécution sans privilèges, une configuration supplémentaire peut être nécessaire sur l'hôte Linux sur lequel le paquet est installé.
Pour des raisons de sécurité, un agent configuré pour une exécution sans privilèges offre une gamme de fonctions légèrement plus restreinte qu'un agent exécuté avec les droits root. Afin de rendre les fonctionnalités manquantes disponibles, vous devez, en tant qu'administrateur, trouver des méthodes qui soient à la fois efficaces et compatibles avec les directives de sécurité de votre organisation et les conventions de la distribution Linux utilisée.
|
Notez que ce chapitre ne propose pas de solution unique optimale, ni pour la configuration fournie avec les paquets d'agent, ni pour celle effectuée sur l'hôte. Toutes les solutions possibles et raisonnables doivent s'appuyer sur les distributions utilisées, les directives opérationnelles de votre organisation et la facilité de maintenance. |
3.1. Configuration d'sudo
Nous avons ajouté une fonction wrapper pour le script de l'agent, qui préfixe les commandes nécessitant généralement des privilèges de haut niveau avec « sudo ».
Cela concerne, dans Checkmk, 2.4.0 mdadm (pour lire l'état de divers RAID logiciels et disques chiffrés), mailq (pour lire la file d'attente des e-mails du MTA Postfix), ainsi que les scripts de surveillance des sites Checkmk.
Vous trouverez des exemples de configuration pour sudo dans le répertoire d'installation de l'agent, dans le sous-dossier default/package/agent/checkmk_agent_sudoers_template.
Vous pouvez transférer les lignes requises vers votre fichier /etc/sudoers ou copier l'intégralité du fichier vers /etc/sudoers.d (non recommandé).
Adaptez les entrées en conséquence.
Par exemple, dans certains cas, aucune autorisation de superutilisateur n'est requise pour lire la file d'attente des e-mails et l'ID utilisateur sous lequel le MTA est exécuté peut être utilisé.
3.2. Exécution des plug-ins d'agent sans privilèges root
Pour l'exécution des plug-ins d'agent, nous vous recommandons de garantir l'accès aux informations requises via les permissions de fichiers, les affectations de groupes ou les listes de contrôle d'accès. La liste suivante présente les méthodes possibles :
Ajoutez l'utilisateur sous l'ID duquel le script de l'agent est exécuté à un groupe autorisé à lire les données requises dans la surveillance.
Modifiez les droits d'accès ou l'affectation de groupe des fichiers de périphériques (par exemple via des règles d'
udev) afin que l'utilisateur non privilégié puisse y accéder.
3.3. Exécution des plug-ins d'agent avec des privilèges root
Si un plug-in d'agent nécessite des privilèges root pour s'exécuter, vous disposez des options suivantes :
Si nécessaire, exécutez les plug-ins via une tâche cron et redirigez leur sortie vers un fichier de spool. Avec des intervalles supérieurs à une minute entre les exécutions, vous couvrez également les plug-ins qui nécessiteraient autrement une exécution asynchrone.
Si vous avez déjà créé des paquets d'agent avec la règle « Plug-ins, local checks and MRPE for non-root users », vous devez alors déplacer les plug-ins qui doivent être exécutés en tant que root vers les répertoires configurés et appliquer la configuration pour «
sudo».
4. Déploiement classique
Une exécution sans privilèges est également possible sans contrôleur d'agent ou si l'installation ne peut pas être effectuée via un paquet DEB ou RPM.
4.1. Installation sans gestionnaire de paquets
Lorsque vous utilisez les paquets TGZ fournis au format « .tar.gz », vous devez vous assurer que les autorisations sont correctement attribuées après l'installation.
Servez-vous d'un exemple d'installation que vous avez effectuée sous Linux avec un gestionnaire de paquets comme guide.
|
Nous ajouterons progressivement des informations supplémentaires à cette section. |
4.2. Exécution sans Agent Controller
Si l'Agent Controller ne peut pas ou ne doit pas être utilisé, l'appel non chiffré via (x)inetd ou l'appel chiffré via Secure Shell sont tous deux possibles.
Des modifications mineures sont nécessaires par rapport à l'appel avec les droits root.
Xinetd
Si l'Agent Controller est désactivé ou incompatible, le fichier de configuration pour xinetd fourni dans le répertoire d'installation sous default/package/config/xinetd-service-template.cfg est activé.
Ce fichier contient déjà l'utilisateur sans privilèges spécifié par la règle d'agent.
Si vous utilisez un autre super-serveur Internet (par exemple, l'inetd d'OpenBSD), créez la configuration conformément à sa documentation.
Vous trouverez des exemples dans l'article Surveillance de Linux en mode hérité.
Secure Shell
L'appel via SSH correspond également à la procédure décrite dans l'article « Surveillance de Linux en mode hérité ».
Seuls le chemin d'accès au fichier de configuration .ssh/authorized_keys et le nom d'utilisateur utilisé doivent être adaptés à l'utilisateur non privilégié que vous utilisez.