NFS Volume in Docker-Host oder Container mounten?

[polyphase]

Ich bin gerade dabei ein NFS Mount für einen Docker Container einzurichten, welcher die Daten nicht auf dem Docker Host, sondern auf einem NAS ablegen soll.

Wie habt ihr das gelöst?
Ich finde die Angaben im Netz, teilweise echt widersprüchlich.

Sicherheitstechnich müsste es doch "ein wenig sicherer" sein, wenn der Docker Host das NFS Share mounted und ich dem Container nur ein Ordner in dem Mount als Volume durchreiche. Oder verstehe ich das falsch?

Klar NFS hat quasi keine Sicherheit, da es nur auf die IP Adresse schaut. Aber mit SMB arbeiten, finde ich in einer nur Linux Umgebung irgendwie komisch.

 

[up.whatever]

Klar NFS hat quasi keine Sicherheit, da es nur auf die IP Adresse schaut

Wenn du bei NFS Sicherheit benötigst musst du Kerberos verwenden.

 

[polyphase]

Ich erkläre mal was ich überhaupt vorhabe, damit das ggf. es etwas klarer wird,
bevor es Schimpfe gibt 😅

Im Grunde geht es mir darum:
Ich habe eine Maschine auf der Docker läuft mit den ensprechenden Containern.
Nun möchte ich das die Container ihre Daten auf einem vorhandenen TrueNAS ablegen, da dort die entsprechenden Vorkehrungen zwecks Backups usw. getroffen sind.

Das alles in ein Homelab und nur von Außen per VPN erreichbar, wobei die betreffenden Container und das TrueNAS durch die Firewall nochmals zusätzlich hinter dem VPN abgesichert sind.

Was ich jetzt schon gemacht habe ist, das ich "mapproot User" und "mapproot Group" auf der TrueNAS NFS Freigabe auf einen normalen Benutzer gesetzt habe.
Somit sollte (wenn ich das richtig verstanden habe), wenn die Docker Maschine versucht mit dem root User auf das Share zuzugreifen, intern in TrueNAS das auf den normalen User umgebogen wird.

Auszug aus dem TrueNAS Forum:
What setting the MAPROOT does is that it maps the root user of the machine accessing the freenas to an non-root user on the freenas box.

 

[HerrRossi]

Ich versuche das mit NFS auch schon seit Tagen, komme aber nicht weiter. Mit einer Samba-Share hat es dann geklappt, als ich aber eine neue Liste zu pihole hinzufügen wollte, kam die Meldung, dass die Datenbank schreibgeschützt wäre. Nix funktioniert, das ist echt frustrierend 🤦‍♂️

 

[polyphase]

Also NFS Zugriff habe ich jetzt,
ich habe einfach mal in Portainer (das läuft auf der Docker Maschine) ein Volume angelegt das auf das NFS Share zeigt.

Nach der Umstellung von maproot auf einen dedizierten User, habe ich jetzt auch Zugriff, kann Daten erstellen, löschen usw.

Ich bin mir halt jetzt nur nicht sicher ob das Best Practise ist, oder ob ich das komplett falsch mache.

 

[andy_m4]

Wenn du bei NFS Sicherheit benötigst musst du Kerberos verwenden.

Nicht unbedingt. Inzwischen gibts auch die Möglichkeit NFS mit TLS abzusichern und Du weist Dich mit einem X.509 Zertifikat gegenüber dem Server aus.

 

[polyphase]

Mir geht es beim Thema Sicherheit eigentlich nur darum:

Container A sieht Share A und nicht B
Container B siehr Share B und nicht A

Daher war meine Frage, ist es besser das jeweilige Share im Container direkt zu Mounten oder auf dem Docker Host ein gemeinsames Share zu mounten, in dem Unterordner sind, die jeweils einzeln im entsprechenden Container gemounted sind?

Oder habe ich einen kompletten Denkfehler?

Ergänzung (1. Mai 2023)

Edit:
Ich hab jetzt auf dem TrueNAS einen Test Benutzer angelegt mit der UID 3004 und GID 3004.

Nun habe ich in der Docker Compose File (Portainer Stacks) folgendes eingetragen:

version: "3"
services:
  ubuntu1:
    container_name: ubuntu1
    image: ubuntu:latest
    user: 3004:3004
    volumes:
      - nfs1:/nfs
    restart: on-failure
    command: ["sleep","infinity"]




volumes:
  nfs1:
    driver_opts:
      type: nfs
      o: addr=xx.xx.xx.xx,nfsvers=4
      device: :/mnt/pool1/Docker/test

Der Container mountet das Share problemlos und auch die Zugriffsrechte passen.
Ich konnte auch problemlos die Datei "wurst.txt" anlegen.

Auf der TrueNAS Maschine sieht das dann so aus:

-rw-r--r-- 1 testuser testuser 0 May  1 20:38 wurst.txt

Das entspricht auch den gesetzen Werten für das Dataset:

 

[polyphase]

Hier ist ne super Beschreibung zum Thema NFS Shares:
https://www.ixsystems.com/documentation/truenas/11.3-U5/sharing.html#unix-nfs-shares

Auch das man unbedingt maproot User oder Mapall User benutzen sollte, damit der Client keinen root Zugriff auf das Filesystem bekommt.

 

[HerrRossi]

Hier ist ne super Beschreibung zum Thema NFS Shares:
https://www.ixsystems.com/documentation/truenas/11.3-U5/sharing.html#unix-nfs-shares

RTFM sollte man halt doch manchmal machen

 

[polyphase]

Lustigerweise ist das bei der TrueNAS Scale Doku echt bescheiden erklärt, daher habe ich mir Mal gedacht schauste in die TrueNAS Core Doku.

Bingo!

 

[andy_m4]

Ist jetzt eigentlich Dein Problem bzw. Deine Frage gelöst? Mir ist zwar so, aber ich bin mir nicht 100%ig sicher.

 

[polyphase]

Sieht so aus,
mir wär's wichtig das es keinen Robotzugriff auf das Share gibt, da die meisten Container als root laufen (ist so ein docker Ding).

Soweit ich das verstanden habe, gibt's dann auch keine Probleme mehr mit den Permissions/User IDs, da TrueNAS das einfach komplett auf den eingestellten User umbiegt.

 

[HerrRossi]

Der Container mountet das Share problemlos und auch die Zugriffsrechte passen.
Ich konnte auch problemlos die Datei "wurst.txt" anlegen.

Spannend wird es, wenn ein Container selber etwas anlegen oder schreiben soll. Pihole macht mich in der Beziehung fertig.

 

[polyphase]

Ich hab die Datei ja aus dem Container angelegt. Einfach nen Ubuntu Container gestartet mit Shell

 

[polyphase]

@HerrRossi
Schau mal in der Dokumentation deines Pihole Containers, ob da eine andere UID und GID verwendet wird, wenn ja mach das folgendermaßen (musste ich bei Radicale auch machen).

• erstelle auf dem NAS eine Gruppe mit der entsprechenden GID
• erstelle auf dem NAS einen Nutzer mit der entsprechenen UID
• erstelle das Dataset und vergebe die Rechte enstprechen an den neuen User+Gruppe
• Erstelle das NFS Share und setze "maproot user" und "maproot group" auf den neuen User+Gruppe
• erlaube den entsprechenden Host (IP) auf dem der Container läuft
• binde das NFS Share in deinem Container ein

Sollte nun funktionieren

 

[HerrRossi]

Danke @polyphase das gucke ich mir heute Abend an!

 

[HerrRossi]

Funktioniert nicht.

Mit NFS bekomme ich gar nicht erst hin, dass das Volume erkannt wird.

Mit Samba wird das Volume erkannt, ich kann aber trotz user "pihole" und identischer uid und guid nichts auf dem share schreiben.

Wenn ich aber mit dem Linux Dateimanager auf die Share mit dem user "pihole" anmelde, dann kann ich da alles machen. Ist doch echt komisch.

pihole@2749eb7ba2cf:/etc/pihole$ touch test
touch: cannot touch 'test': Permission denied

 

[Skysnake]

Grundsätzlich eine Sache. Mounten im Container macht man nicht, da hierfür höhere Capabilities notwendig sind und man damit weitere Fragen bezüglich Sicherheit einhandelt.

Es wird also von Host aus gemounted.

Und da heißt das Zauberwort dann NFSv4 weil dieses auch Authentifizierung zulässt.

Ich glaub mehr muss man dann eigentlich nicht mehr sagen. Der Rest kann dann über rootless docker und eben id Mapping laufen. Wenn man nur von einer Art Devices drauf zugreift ok, wenn nicht, dann kommt man von einem Problem zum nächsten. Das macht wenig Spaß.

Ansonsten podman und Konsorten sind nicht gleich docker. Docker kann z.b. auch NFS shares direkt als Name Volumens mounten.

 

[polyphase]

@Skysnake
Ich glaube ich hab mich hier falsch ausgedrückt 😅

• Mit im Host mounten meinte ich das Einbinden des NFS Shares über die fstab des Hostes.
• Mit im Countainer mounten meinte ich das Einbinden über Docker Volumes.

Direkt im Container mounten, also dort über die Shell, geht das überhaupt?

 

[Skysnake]

Ja geht wenn du dem Container die entsprechenden capabilities mitbgibst.