Sicherheitsproblem bei der Bereitstellung von MongoDB bei Google Cloud Compute und KeyFile-Problem

Sicherheitsproblem bei der Bereitstellung von MongoDB bei Google Cloud Compute und KeyFile-Problem

Ich bin heute auf dieses super nervige Problem gestoßen.

Im Grunde habe ich eine MongoDB-Datenbank mit dem Angebot von GCP Marketplace eingerichtet. Es richtet einen primären Knoten, einen sekundären Knoten und einen Arbiter ein. Das ist super cool. Was es nicht tut, ist Sicherheit. Also überhaupt nicht. Also war es ganz natürlich, dass ich es selbst einrichten musste. Nun, jetzt, 20 Stunden später und nach ein paar guten Schlägen in mein eigenes Gesicht, kämpfe ich immer noch damit, es zum Laufen zu bringen.

Im Wesentlichen ist dies meine Teilkonfiguration:

security:
  authorization: enabled
  keyFile: '/etc/mongodKey'

Wenn ich das auskommentiere, keyFilewird die Instanz ausgeführt. Sie kann sich aber nicht mit anderen Knoten verbinden, da die Sicherheit aktiviert ist. Und nein, ich kann sie nicht deaktivieren, bist du verrückt?

Die Sache mit der Schlüsseldatei ist jedoch … So wie ich das verstehe, mongodkann ich sie nicht öffnen, also startet sie nicht. Ich nehme an, /etcdas ist kein guter Ort, um sie abzulegen? Ich habe es mit anderen Ordnern versucht, aber ohne Erfolg. Nichts funktioniert.

Und ich brauche diese Sicherheitsmaßnahme, da meine Kollegen, die Robo 3T verwenden, eine Verbindung zur Datenbank herstellen müssen. Daher kommt das Löschen der externen IP-Adresse nicht in Frage.

Was soll ich falsch machen? Bitte helfen Sie mir, ich reiße mir die Haare aus.

Dies ist die Ausgabe von sudo service mongod status:

● mongod.service - MongoDB Database Server
   Loaded: loaded (/lib/systemd/system/mongod.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2019-08-21 15:28:08 UTC; 4min 29s ago
     Docs: https://docs.mongodb.org/manual
  Process: 1024 ExecStart=/usr/bin/mongod --config /etc/mongod.conf (code=exited, status=1/FAILURE)
 Main PID: 1024 (code=exited, status=1/FAILURE)
Aug 21 15:28:08 m-vm-0 systemd[1]: Started MongoDB Database Server.
Aug 21 15:28:08 m-vm-0 systemd[1]: mongod.service: Main process exited, code=exited, status=1/F
Aug 21 15:28:08 m-vm-0 systemd[1]: mongod.service: Unit entered failed state.
Aug 21 15:28:08 m-0 systemd[1]: mongod.service: Failed with result 'exit-code'.

Bearbeiten:

Ich habe das überprüft mongod.log. Ja, es ist ein Berechtigungsproblem. Und ich kann es nicht lösen.

Ich habe es versucht, sudo chmod 400 /etc/mongodKeyaber es passiert nichts. Kann mir bitte jemand sagen, wo ich die Schlüsseldatei ablegen kann, damit sie von MongoDB gelesen werden kann? Das ist sehr wichtig!

Antwort1

Wenn Sie die GCP MongoDB-Marktplatzbereitstellung namens „MongoDB“ verwenden, mit der Sie die Replikation einrichten können, sollten Sie Folgendes wissen:

Sie richten die Sicherheit nicht in der Erstkonfiguration ein, daher gibt es zwei Optionen:

  1. Schalten Sie die externe IP aus
  2. Aktivieren Sie die Autorisierung immongod.conf

Wenn Sie sich für die erste Lösung entscheiden, können Sie von keiner anderen externen Quelle aus problemlos eine Verbindung zur Datenbank herstellen.

Wenn Sie sich für die zweite Lösung entscheiden, müssen Sie Folgendes tun:

  1. Generieren Sie einen Schlüssel. Den gesamten Vorgang finden Sie hier:https://docs.mongodb.com/manual/tutorial/enforce-keyfile-access-control-in-existing-replica-set/

  2. Kopieren Sie den Dateiinhalt

  3. SSH-Zugriff auf alle Ihre Compute Engine-Instanzen
  4. Wählen Sie ein Verzeichnis
  5. sudo touch <path to key>
  6. sudo nano <path to key>
  7. Fügen Sie den von Ihnen generierten Schlüssel auf Ihrem Computer ein und speichern Sie
  8. sudo chmod 600 <path to key>
  9. sudo chown mongodb: <path to key>
  10. Aktualisieren Sie Ihre mongod.confunter/etc/mongod.conf
  11. Auskommentieren security, authorization,keyFile
  12. Geben Sie unter „Schlüssel“ den Pfad keyFilezu Ihrer Schlüsseldatei an
  13. Stoppen Sie alle Instanzen und starten Sie sie erneut.

Jetzt hat MongoDB Zugriff auf die Schlüsseldatei.

Was für ein Albtraum. Und chmod 400 <path to key>hat bei mir nicht wie in der Dokumentation angegeben funktioniert. Ich musste es auf einstellen chmod 600 <path to key>.

verwandte Informationen