MongoDB und FreeIPA im Einklang

Copyright, 123RF

Ticket-Dienst

MongoDB und FreeIPA sind zwei beliebte OpenSource-Tools, die beide schon einmal Thema in der Admin-Story waren. Diesmal geht es darum, wie sich die beiden Tools miteinander verbinden lassen.
Drahtlose Netzwerke sind überall: Zu Hause, im Café und in der Firma. Im Gegensatz zu Kabelnetzen verliert der Admin bei WLANs allerdings schnell die ... (mehr)

Die NoSQL-Datenbank MongoDB ist recht großzügig, was den Zugriff auf die Datenbanken und den darin gespeicherten Collections betrifft. Von Haus aus hat hier nämlich jeder Zugriff. Natürlich besteht die Möglichkeit, diesen Zugriff einzuschränken, sodass ein Benutzer sich mittels Namen und Passwort authentifizieren muss. MongoDB greift hierfür auf die System-Collection »system.users« zurück. Über die Methode »db.addUser()« füllt man die Datenbank dann mit den gewünschten Account-Daten und Zugriffsrechten. Benutzer sind hierbei für jede gewünschte Datenbank zu definieren. Dies könnte für die Datenbank »football« wie folgt aussehen:

# mongo localhost/football
db.addUser( { user: "tscherf",
              pwd: "redhat",
              roles: [ "readWrite","dbAdmin" ]
        } )

Dieser Aufruf erzeugt ein Benutzerobjekt für den Zugriff auf die Datenbank »football« . Das Passwort wird dabei als SHA256-Hash hinterlegt. Soll der gleiche Benutzer auch Zugriff auf eine andere Datenbank bekommen, muss man den Benutzer auch dort definieren.

Vorsicht

Die Authentifizierung und Autorisierung eines Benutzers nimmt MongoDB stets auf Datenbankebene vor.

Kommt das gleiche Passwort zum Einsatz, ist auch der Passwort-Hash für die einzelnen Datenbanken identisch. Dies sollte man im Hinterkopf behalten, wenn man mit der Challenge-Response basierten Authentifizierung auf dem Datenbank-Server arbeitet. Ist der Password-Hash einmal geknackt, bekommen Angreifer Zugriff auf alle Datenbanken eines Benutzers. Es wird daher empfohlen, Applikationen mit unterschiedlichen Account-Namen und Passwörtern auszustatten.

Der authentifizierte Zugriff auf den Server erfolgt mithilfe des Kommandozeilentools »mongo« , das voraussetzt, dass der Server zuvor mit der Option »--auth« gestartet wurde ( Listing 1 ). Die Option ist in der Konfigurationsdatei »/etc/mongod.conf« von Haus aus nicht gesetzt.

Listing 1

MongoDB mit Passwort

 

Abbildung 1: Zur Administration der MongoDB gibt es auch einige GUIs wie etwa Robomongo.

MongoDB Enterprise

In der Enterprise-Edition von MongoDB [1] steht neben der Challenge-Response-basierten Authentifizierung auch die Kerberos-Methode zur Verfügung. Das ermöglicht, für die Anmeldung bei MongoDB auf Benutzerkonten eines bereits bestehenden Identity-Management-Systems zurückzugreifen.

In »system.users« ist dann nur noch zu definieren, welche Rechte die Kerberos-Benutzer für eine bestimmte Datenbank haben. Die Rechte werden mithilfe von Rollen abgebildet. Statt des Benutzernamens muss bei der Kerberos-basierten Authentifizierung das Kerberos-Principal des Benutzers oder des Services angeben werden.

In meinem Beispiel greife ich auf das Identity-Management-Framework FreeIPA zurück. Es enthält neben einem LDAP-Server auch einen Kerberos-Server, der zur Authentifizierung der MongoDB-Benutzer zum Einsatz kommen soll. Mehr Informationen zur FreeIPA-Konfiguration sind in meinem ADMIN-Artikel [2] zu finden.

Damit MongoDB seine Benutzer mittels einer externen Quelle – dem Kerberos-Server – authentifiziert, müssen die folgenden Optionen in der Konfigurationsdatei des Datenbank-Servers stehen:

auth = true
setParameter=authenticationMechanisms=GSSAPI

Die erste Option aktiviert die Authentifizierung, die zweite definiert die Kerberos-Methode. Fehlt die Methode, verwendet MongoDB die zuvor besprochene Challenge-Response-Variante. An der Stelle sei noch einmal der Hinweis erlaubt, dass die Authentifizierungsvariante mittels GSSAPI lediglich in der Enterprise-Edition möglich ist, die Community-Edition gibt an dieser Stelle einen Fehler aus. Die Enterprise-Edition kann jedoch in einer zeitlich und funktional unlimitierten Evaluierungsversion von der MongoDB-Enterprise-Website heruntergeladen werden [1] .

Der Datenbank-Server muss Teil der FreeIPA-Domäne sein, damit der Zugriff funktioniert. Sollte dies nicht bereits der Fall sein, nimmt ein Aufruf von »ipa-client-install« den Server in die Domäne auf. Im Anschluss muss man für den MongoDB-Service ein Kerberos-Principal auf dem FreeIPA-System anlegen. Hierbei hilft das Tool »ipa« :

# kinit admin
# ipa service-add mongodb/fedora.virt.tuxgeek.de

Im Anschluss ist die Keytab-Datei des Services auf das Datenbank-System zu übertragen, am einfachsten mit »ipa-getkeytab« :

# ipa-getkeytab -s ipa1.virt.tuxgeek.de -p mongodb/fedora.virt.tuxgeek.de -k /etc/mongodb.keytab

Die Keytab-Datei sollte dabei dem Benutzer »mongod« gehören und nur für ihn lesbar sein. Alternativ besteht die Möglichkeit, die Keytab-Datei direkt vom Datenbank-System aus zu generieren. Das setzt aber voraus, dass das Tool »ipa-admintools« installiert ist.

MongoDB muss nun natürlich noch wissen, welche Keytab-Datei zum Einsatz kommen soll. Diese Information übergebe ich mittels »KRB5_KTNAME=/etc/mongodb.keytab« in der Datei »/etc/sysconfig/mongod« . Wer keine paketierte Version von MongoDB besitzt, kann den Server auch mit allen notwendigen Optionen von der Kommandozeile aus starten ( Listing 2 ).

Listing 2

Server-Start

 

Benutzereinträge in der Collection »system.users« können nun einen Kerberos-Principal enthalten, um zu bestimmen, welcher Benutzer Zugriff auf eine bestimmte Datenbank bekommt ( Listing 3 ).

Listing 3

Kerberos-Principal

 

Um nun einen Kerberos-authentifizierten Zugriff auf die Mongo-Shell zu erhalten, muss man zuerst ein entsprechendes Ticket-Granting-Ticket (TGT) vom Kerberos-Server anfordern. Dies geschieht entweder beim Login auf einem System durch ein entsprechendes PAM-Modul oder aber ganz einfach mittels »kinit« . Danach kann man dann die Mongo-Client-Anwendung mit allen notwendigen Optionen aufrufen, um sich dann mit der gewünschten Datenbank verbinden zu lassen ( Listing 4 ).

Listing 4

Verbindung per Kerberos

 

Der Aufruf von »klist« bestätigt schließlich, dass der Benutzer nun nicht nur über einen Kerberos-TGT verfügt, sondern ebenfalls ein Service-Ticket für die Datenbank erhalten hat ( Listing 5 ).

Listing 5

Service-Ticket

 

Anstatt die Mongo-Shell mit allen notwendigen Parametern aufzurufen, lässt sich eine Kerberos-authentifizierte Verbindung zu einer Datenbank auch mit dem folgenden Statement aus der Shell heraus aufrufen:

use $external
db.auth( { mechanism: "GSSAPI", user: "tscherf@VIRT.TUXGEEK.DE" } )

Wer Lust hat, kann an dieser Stelle auch noch X.509-Zertifikate für seinen MongoDB-Server und sämtliche Clients vom FreeIPA-Framework ausstellen lassen. Hiermit lässt sich dann die Verbindung zwischen Server und Client verschlüsseln. Alle hierfür notwendigen Tools sind dank des FreeIPA-Frameworks bereits vorhanden.

Der Autor

Thorsten Scherf arbeitet als Principal Consultant für Red Hat EMEA. Er ist oft als Vortragender auf Konferenzen anzutreffen. Wenn ihm neben der Arbeit und Familie noch Zeit bleibt, nimmt er gerne an Marathonläufen teil.

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

NoSQL-Datenbank MongoDB jetzt stabiler

MongoDB ist nun auch im Betrieb auf nur einem Rechner gegen Abstürze gesichert.

Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023