Wie kann ich die Berechtigungen für gemountete Datenträger in Docker von Alpine verwalten?

3852
Sean Quinn

Wenn Sie ein Bild erstellen, können Sie Eigentümer ( chown) zuweisen und Berechtigungen ( chmod) für Pfade innerhalb des Bildes ändern . Wenn jedoch ein Volume vom Host oder einem anderen Container bereitgestellt wird, sind die Berechtigungen für dieses Volume vorhanden, wodurch möglicherweise ein Benutzer / eine Gruppe eingeführt wird, die dem Container, in dem er bereitgestellt ist, unbekannt ist.

Ich bin an einer vorgeschriebenen Methode interessiert (falls vorhanden), um Berechtigungen für Benutzer unter einem Alpine Docker-Image für vom Host gemountete und vom Container gemountete Datenträger zu behandeln.

Die zwei möglichen Optionen, die mir einfallen, sind:

  1. Verwenden Sie denselben Benutzer und dieselbe Gruppe zwischen Containern und bereitgestellten Volumes.
  2. Verwenden Sie ACLs, um die Berechtigungen zu steuern.

Gibt es einen empfohlenen Ansatz, um Berechtigungsprobleme für gemountete Datenträger zu beheben, insbesondere wenn die UID / GID der Besitzer nicht mit Benutzern / Gruppen in einem Container übereinstimmt? Z.B

In meinem Alpine Docker-Image hat mein www-dataBenutzer eine UID / GID von 82 (siehe: nginx Www-Data-Benutzer-ID ). Wenn ich ein Volume aus einem anderen Container oder dem Host mounte, bei dem ein Benutzer mit der Uid 1001und GID 1001das Volume besitzt, wie Ich befasse mich mit den unterschiedlichen Eigentumsverhältnissen und Berechtigungen.

Hinweis: Einige Anwendungsframeworks (z. B. Symfony ) empfehlen die Verwendung von etwas wie setfacl[ 1 ] zum Verwalten von Berechtigungen. Dies scheint jedoch unter einem Alpine Docker-Image mit AUFS nicht möglich zu sein, da die Operation "nicht unterstützt" wird.

Ist die Verwendung von ACLs im Docker ein Anti-Pattern?

3

1 Antwort auf die Frage

2
Sean Quinn

Hinweis: StackOverflow stellt die folgende Frage: Wie können Berechtigungen für freigegebene Docker-Volumes am besten verwaltet werden? die ähnlich zu den oben genannten und zahlreichen Antworten, mit der vorherrschenden Antwort da dies ein .

Beim Experimentieren und beim Lesen zahlreicher Quellen, die nach einer verbindlichen Antwort oder einem gemeinsamen Muster suchen, habe ich Folgendes identifiziert:

Beim Ausführen von Docker-Outside-of-Docker (DooD) werden Host-Daten-Volumes vom zugrunde liegenden Host bereitgestellt. Ich erinnere mich, dass ich in einem Blogbeitrag über einige Erwähnungen gestolpert bin, aber für mein Leben kann ich es jetzt nicht finden (wenn / wenn ich dies tue, werde ich diese Antwort aktualisieren). Kurz und bündig: Wenn Sie Docker über einen gemeinsam genutzten docker.sockContainer in einem Container ausführen, versucht Docker, Volumes vom zugrunde liegenden Host aus bereitzustellen . Wenn Sie Volumes aus einem anderen Container bereitstellen, ist dieses Problem nicht aufgetreten.

Zuweisen von Berechtigungen und Besitz Das Problem, das ich oben erwähnt habe ( setfaclohne Funktionieren), scheint ein Benutzerproblem gewesen zu sein. Ich muss versucht haben, es unter den Berechtigungen des Nicht-Root-Benutzers oder für ein Verzeichnis auszuführen, an dem mein Benutzer keinen Besitz hatte. Um Eigentumsprobleme zu umgehen, können Sie ein docker-entrypoint.shSkript verwenden, das entweder chownoder setfaclals Root-Benutzer vor dem Ausführen des Befehls als Benutzer für das Image verwendet wird. Bis jetzt habe ich zwei mögliche Optionen zur Behandlung von Besitz- und Berechtigungsproblemen identifiziert:

  • Verwenden Sie sudodiese Option, um den Besitzer zu ändern oder Zugriffssteuerungslisten festzulegen.
  • Lassen Sie den Container mit dem rootBenutzer laufen und gehen Sie zu einem anderen Benutzer über, um den Befehl mit gosu oder su-exec auszuführen .

Ich habe die beiden obigen Beobachtungen für meinen selbstverschreibenden Ansatz kombiniert, also ...

  1. Beim Einhängen eines Host-Volumes in einen Docker-Container, der auch das Host-Volume verwendet docker.sock, wird empfohlen, dass die Verzeichnisse übereinstimmen. Wenn zum Beispiel das Volume mount in der Dockerfile als /var/datadann mount /var/datavom Host deklariert wird (z -v /var/data:/var/data. B. ). Dies ist insbesondere dann der /var/dataFall, wenn Sie Dateien oder Verzeichnisse haben, unter denen Sie aus dem Container einen neuen Container bereitstellen möchten.
  2. Seien Sie proaktiv in Bezug auf Berechtigungen. Fügen Sie immer eine docker-entrypoint.shDatei hinzu, die zumindest den Besitz oder die Zugriffskontrolle für ein eingehängtes Verzeichnis aktualisiert.

Verwandte Probleme