1. Einleitung
In den kommerziellen Editionen von Checkmk
können Sie Agentenpakete so konfigurieren, dass diese auf dem Host von einem unprivilegierten Benutzer, das heißt nicht von root, ausgeführt werden.
Vollständig nutzbar ist dieses Feature zunächst für Linux-Agenten, die als DEB- oder RPM-Paket installiert werden.
Voraussetzung für die unprivilegierte Ausführung ist es, das Agentenpaket innerhalb eines einzigen Verzeichnisses zu installieren. Die Option zur Auswahl eines Installationsverzeichnisses ist aber nicht nur für Linux, sondern auch für Solaris und AIX verfügbar.
Die beiden verwandten Regelsätze Installation paths for agent files (Linux, UNIX) und Run agent as non-root user (Linux) sind abgekündigt. Es ist geplant, beide in der Checkmk-Version 2.5.0 zu entfernen.
 |
Die hier vorgestellte Funktionalität ist ein Technical Preview, also die Vorschau auf ein neues Feature, das bis auf weiteres Wandel und Erweiterung unterworfen sein wird. Während dieser Phase ist es möglich, dass Funktionalität nicht nur hinzugefügt, sondern auch so umgebaut wird, dass bereits vorhandene Konfiguration obsolet wird und Sie diese neu erstellen müssen. Wir bitten dafür um Verständnis. |
2. Konfiguration der Agentenpakete
Die Konfiguration der Agentenpakete erfolgt in der Agentenbäckerei, die Sie über Setup > Agents > Windows, Linux, Solaris, AIX öffnen. Klicken Sie den Knopf Agent rules. Unter Agent rules > Linux/Unix agent options finden Sie die Regel Customize agent package (Linux).
2.1. Installationsverzeichnis festlegen
Bei Directory for Checkmk agent können Sie das Installationsverzeichnis festlegen:
In diesem Verzeichnis werden alle Dateien des Agentenpakets installiert, statt in Verzeichnissen wie /etc/, /usr/lib/ oder /var/lib/.
Wählen Sie aus Sicherheitsgründen kein Verzeichnis in einem Home-Verzeichnis eines Benutzers.
Für Solaris und AIX sind Sie damit fertig. Für Linux können Sie zusätzlich noch die unprivilegierte Ausführung festlegen.
2.2. Unprivilegierte Ausführung konfigurieren
Für den Linux-Agenten stehen Ihnen nach Auswahl von Customize user zwei grundlegende Optionen zur Verfügung:
Die Standardwerte Run agent as root, set agent controller user und cmk-agent als Benutzer legen genau das Verhalten fest, was ohnehin das Standardverhalten des Checkmk-Agenten für Linux ist, auch ohne Konfiguration dieser Regel:
Der Agent Controller wird unter cmk-agent ausgeführt und das Agentenskript unter root.
Neu ist jetzt aber die Möglichkeit, einen anderen Benutzer als cmk-agent festzulegen.
Die zweite Option ist Run agent as non-root, set agent user. Damit legen Sie fest, dass zusätzlich zum Agent Controller auch das Agentenskript unter dem festgelegten Benutzer ausgeführt wird — beide also unprivilegiert.
Zudem können Sie Benutzer (UID) und Gruppe (GID) numerische IDs zuweisen. Beachten Sie hier die Konventionen Ihrer Linux-Distribution und möglicherweise vorhandene Limitationen verwendeter Dateisysteme.
Mit der letzten Option bestimmen Sie, ob der in dieser Regel gewählte Benutzer erstellt werden soll, falls er nicht existiert.
3. Unprivilegierte Ausführung auf dem Host konfigurieren
Falls Sie Agentenpakete für unprivilegierte Ausführung konfiguriert haben, kann zusätzliche Konfiguration auf dem Linux-Host erforderlich werden, auf dem das Paket installiert wird.
Aus Sicherheitsgründen bietet ein für unprivilegierte Ausführung konfigurierter Agent einen etwas geringeren Funktionsumfang als ein mit Root-Rechten ausgeführter Agent. Um die fehlende Funktionalität verfügbar zu machen, müssen Sie als administrierende Person Methoden finden, die sowohl effektiv sind, als auch mit den Sicherheitsrichtlinien Ihres Unternehmens und den Konventionen der eingesetzten Linux-Distribution vereinbar sind.
|
Beachten Sie, dass es weder für die mit den Agentenpaketen ausgelieferte Konfiguration, noch die in diesem Kapitel auf dem Host vorgenommene Konfiguration die eine beste Lösung gibt. Alle möglichen und sinnvollen Lösungen orientieren sich an verwendeten Distributionen, Richtlinien in Ihrem Unternehmen und Wartbarkeit. |
3.1. Konfiguration von sudo
Für das Agentenskript haben wir eine Wrapper-Funktion hinzugefügt, welche Befehlen, die in der Regel erhöhte Privilegien benötigen, sudo voranstellt.
Betroffen davon sind in Checkmk 2.4.0 mdadm (zum Auslesen des Zustandes verschiedener Software-RAIDs und verschlüsselter Laufwerke), sowie mailq (zum Auslesen der E-Mail-Warteschlange des Postfix-MTA).
Beispielkonfigurationen für sudo finden Sie im Installationsverzeichnis des Agenten im Unterordner default/package/agent/checkmk_agent_sudoers_template.
Sie können benötigte Zeilen in Ihre /etc/sudoers übertragen oder die gesamte Datei nach /etc/sudoers.d kopieren (nicht empfohlen).
Passen Sie die Einträge entsprechend an.
Beispielsweise sind in einigen Fällen keine Superuser-Rechte für das Auslesen der E-Mail-Warteschlange notwendig und es kann die Benutzerkennung verwendet werden, unter welcher der MTA ausgeführt wird.
3.2. Agentenplugins
Für die Ausführung von Agentenplugins empfehlen wir, über Dateiberechtigungen und Gruppenzuordnungen Zugriff auf benötigte Informationen sicherstellen. Die folgende Liste zeigt mögliche Methoden:
Fügen Sie den Benutzer, unter dessen Kennung das Agentenskript ausgeführt wird, einer Gruppe hinzu, die im Monitoring benötigte Daten auslesen kann.
Ändern Sie Zugriffsrechte oder Gruppenzuordnung von Gerätedateien (beispielsweise über
udev-Regeln) so, dass der unprivilegierte Benutzer zugreifen kann.Führen Sie gegebenenfalls Plugins per Cronjob aus und leiten Sie deren Ausgabe in eine Spool-Datei um.
Führen diese Maßnahmen nicht zum gewünschten Ziel, steht darüber hinaus die Möglichkeit zur Verfügung, mit der Regel Plug-ins, local checks and MRPE for non-root users die ausführenden Benutzer für bestimmte Verzeichnisse individuell zu bestimmen.
Diese Regel erzeugt eine Agentenkonfiguration, die automatisch installiert wird, und eine weitere Konfiguration für sudo, die Sie (wie oben beschrieben) ausbringen müssen.
|
Vorgenommene Anpassungen an mit Checkmk ausgelieferten Agentenplugins können Sie uns gerne zukommen lassen. Dies kann über einen Pull-Request geschehen, ein Support-Ticket oder Hinweise im Checkmk-Forum. Best Practises für Plugin-Entwickler werden wir dem Artikel zur Entwicklung agentenbasierter Check-Plugins nach und nach hinzufügen. |
3.3. Automatische Agenten-Updates
 |
Die gegenwärtige Implementierung des Agent Updaters als Agentenplugin ist nicht mit der unprivilegierten Ausführung kompatibel. Wir arbeiten an notwendigen Änderungen an der Architektur. Greifen Sie derweil auf andere Softwareverteilungslösungen zurück. |
4. Legacy Deployment
Auch ohne Agent Controller und wenn die Installation nicht über ein Debian- oder RPM-Paket erfolgen kann, ist die Ausführung unprivilegiert möglich.
4.1. Installation ohne Paketmanager
Bei Verwendung der im .tar.gz-Format bereitgestellten TGZ-Pakete müssen Sie nach der Installation selbst sicherstellen, dass Berechtigungen korrekt gesetzt sind.
Orientieren Sie sich dabei an einer Musterinstallation, die Sie unter einem Linux mit Paketmanagement durchgeführt haben.
|
Diesen Abschnitt werden wir nach und nach um weitere Hinweise ergänzen. |
4.2. Aufruf ohne Agent Controller
Kann oder soll der Agent Controller nicht verwendet werden, sind sowohl der unverschlüsselte Aufruf per (x)inetd oder der verschlüsselte über Secure Shell möglich.
Gegenüber dem Aufruf mit Root-Rechten sind moderate Modifikationen erforderlich.
Xinetd
Die im Installationsverzeichnis unter default/package/config/xinetd-service-template.cfg mitgelieferte und bei deaktiviertem oder inkompatiblen Agent Controller aktivierte Konfigurationsdatei für xinetd enthält bereits den per Agentenregel definierten unprivilegierten Benutzer.
Falls Sie einen anderen Internet Superserver nutzen (beispielsweise den OpenBSD inetd), erstellen Sie die Konfiguration entsprechend dessen Dokumentation.
Beispiele zeigt der Artikel Linux überwachen im Legacy-Modus.
Secure Shell
Auch der Aufruf via SSH entspricht dem im Artikel Linux überwachen im Legacy-Modus beschriebenen Vorgehen.
Lediglich der Pfad zur verwendeten Konfigurationsdatei .ssh/authorized_keys und der verwendete Benutzername sind auf den bei Ihnen genutzten unprivilegierten Nutzer anzupassen.