Benutzerberechtigungen innerhalb und außerhalb von LXC-Containern?

Ich führe einige Dienste in Docker LXC-Containern auf meinem Server aus und beginne, ernsthafte Dinge damit zu tun.

Eine Sache, die mir nicht klar ist, ist, wie Benutzerberechtigungen innerhalb und außerhalb des Containers funktionieren. Wenn ich beispielsweise MySQL in einem Container ausführe und das Datenverzeichnis auf " /dataDocker-Volume" eingestellt habe, wie wirken sich Berechtigungen innerhalb und außerhalb des Containers auf Zugriffsrichtlinien aus?

Offensichtlich besteht die Idee darin, MySQL als eigenen Benutzer im Container (dh mysql:mysql) auszuführen und ihm Lese- und Schreibrechte für dieses Verzeichnis zu erteilen. Ich gehe davon aus, dass dies ziemlich einfach ist, nur chmoddas Verzeichnis usw. Aber wie funktioniert das außerhalb des Containers? Wie verwalte ich die Zugriffssteuerung auf dieses freigegebene Docker-Volume mit der Bezeichnung "Daten"?

Ich versuche speziell, einen nicht privilegierten Benutzer außerhalb des Docker-Containers ausführen zu können, der regelmäßig auf das freigegebene MySQL-Volume zugreift und die Daten sichert.

Wie kann ich Berechtigungen, Benutzer und Gruppen einrichten, damit ein bestimmter Benutzer auf dem Host Dateien und Ordner auf dem freigegebenen Docker-Volume lesen und schreiben kann?

Seit der Veröffentlichung von 0.9 ist Docker nicht mehr LXCverfügbar und verwendet eine eigene Ausführungsumgebung libcontainer. Ihre Frage ist ein bisschen alt, aber ich schätze, dass meine Antwort immer noch auf die von Ihnen verwendete Version zutrifft.

Schnelle Antwort: Um die Berechtigungen von Volumes zu verstehen, können Sie die Analogie von verwenden mount --bind Host-Dir Container-Dir. Um Ihre Anforderungen zu erfüllen, können Sie alle herkömmlichen Methoden zum Verwalten von Berechtigungen verwenden. Ich denke, ACL ist das, was Sie brauchen .

Lange Antwort: Wie in Ihrem Beispiel haben wir einen Container namens dock mit einem Volume /data.

docker run -tid --name dock -v /usr/container/Databases/:/data \
    centos:latest /bin/bash

Innerhalb des Containers wurde unser MySQL-Server so konfiguriert, dass er das /dataals Datenverzeichnis verwendet. Also haben wir unsere Datenbanken im /dataInneren des Containers. Außerhalb des Containers auf dem Host-Betriebssystem haben wir dieses /dataVolume von /usr/container/Databases/bereitgestellt und weisen einen normalen Benutzer- Bob zu, der Sicherungen der Datenbanken erstellt. Auf dem Hostcomputer konfigurieren wir ACLs für den Benutzer bob .

useradd -u 3000 bob
usermod -R o=--- /usr/container/Databases/
setfacl -R -m u:bob:rwx /usr/container/Databases/
setfacl -R -d -m u:bob:rwx /usr/container/Databases/

Zum Testen erstellen wir ein Backup mit dem Benutzer bob .

su - bob
tar -cvf container-data.tar /usr/container/Databases/

Und tar wird auflisten und Sie können sehen, dass unser Benutzer auf alle Dateien zugreifen konnte.

Wenn Sie jetzt im Container nachsehen, werden getfaclSie feststellen, dass anstelle von bob 3000 angezeigt wird. Dies liegt daran, dass die UID von bob 3000 lautet und sich kein solcher Benutzer im Container befindet, sodass nur die UID angezeigt wird, die er von den Metadaten empfängt . Wenn Sie jetzt einen Benutzer in Ihrem Container mit erstellen, werden useradd -u 3000 bobSie feststellen, dass jetzt getfaclder Name Bob anstelle von 3000 angezeigt wird.

Zusammenfassung : Die Benutzerberechtigungen, die Sie entweder innerhalb oder außerhalb des Containers zuweisen, gelten für beide Umgebungen. So verwalten Sie die Berechtigungen von Volumes, UIDs in Host - Maschine muss von dem UIDs im Behälter unterschiedlich sein .