Jak zablokować UID/GID kontenera i własność woluminu przed aktualizacjami samodzielnie hostowanych aplikacji

Aktualizacje aplikacji hostowanych samodzielnie rzadziej prowadzą do tworzenia plików należących do roota, gdy wdrożenie przypisuje numeryczny kontrakt użytkownika i sprawdza właściciela woluminu przed zastąpieniem kontenera.

Działanie zapobiegawcze polega na tym, aby przestać traktować wewnętrzną nazwę użytkownika obrazu jako stałą tożsamość magazynu danych. Zapisz efektywne wartości UID i GID używane do zapisu danych trwałych, przypisz je do katalogów hosta lub woluminów nazwanych, zachowaj wszelkie ustawienia PUID/PGID oraz przestrzeni nazw użytkowników i przetestuj nowy obraz na niewielkiej ścieżce z prawem zapisu przed pełnym wdrożeniem. Dzięki temu aktualizacja obrazu nie zmieni po cichu numerycznego właściciela konfiguracji, przesłanych plików, baz danych ani metadanych multimediów.

Zapisz numeryczne wartości UID i GID przed aktualizacją

Zarejestruj użytkownika procesu działającego w kontenerze, grupę podstawową, grupy dodatkowe oraz numerycznego właściciela reprezentatywnych plików w każdym montowanym woluminie z prawem zapisu. Zapisz skrót obrazu lub jego wersję obok tej bazowej informacji o właścicielu.

Wskazówki Dockera dotyczące budowania obrazów mówią, że jawne identyfikatory zapobiegają rozbieżnościom po przebudowie, ponieważ użytkownicy obrazów przypisywani automatycznie mogą otrzymywać różne identyfikatory numeryczne podczas kolejnych przebudów.

Zapisuj liczby, a nie tylko nazwy takie jak app czy media. Nowy obraz może ponownie używać tej samej nazwy użytkownika, jednocześnie zmieniając jego UID, a pliki na hoście przechowują numeryczną informację o właścicielu.

Przypisz użytkownika uruchomieniowego w kontrakcie wdrożenia

Jeśli obraz obsługuje bezpośrednie uruchamianie jako konto inne niż root, jawnie określ zamierzonego użytkownika i grupę w Compose lub konfiguracji środowiska uruchomieniowego. Jeśli obraz wymaga fazy inicjalizacji z uprawnieniami roota, udokumentuj, który późniejszy proces faktycznie zapisuje dane trwałe.

Specyfikacja obrazów Open Container definiuje User jako domyślną tożsamość uruchomieniową, co oznacza, że zmieniony obraz może zmienić tożsamość procesu, chyba że wdrożenie celowo ją zastąpi lub zweryfikuje.

Nie wymuszaj dowolnego UID użytkownika innego niż root na obrazach wymagających obsługiwanego modelu inicjalizacji. Kontrakt powinien odpowiadać udokumentowanemu projektowi aplikacji, a jednocześnie zapewniać przewidywalnego właściciela plików trwałych.

Utrzymuj zgodność PUID i PGID z właścicielem na hoście

W przypadku obrazów udostępniających zmienne PUID i PGID przypisz te wartości na stałe w kontrolowanej wersjonowaniem konfiguracji Compose lub środowiska i upewnij się, że katalogi woluminów po stronie hosta należą do odpowiedniego konta usługi.

LinuxServer wyjaśnia, że PUID przypisuje właściciela zapisów z kontenera, dzięki czemu pliki tworzone w mapowanych woluminach pozostają możliwe do zarządzania poza kontenerem.

Przed aktualizacją porównaj skonfigurowane identyfikatory z wynikiem polecenia id na hoście oraz z właścicielami istniejących plików. Nie kopiuj bezrefleksyjnie przykładowej wartości, takiej jak 1000, na serwer, na którym ten identyfikator należy do innej osoby lub usługi.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Uwzględnij przestrzenie nazw użytkowników i mapowanie rootless

Docker lub Podman działające bez uprawnień roota mogą sprawiać, że proces wygląda wewnątrz kontenera jak root, podczas gdy na hoście jest mapowany na UID użytkownika innego niż root. Zapisz tryb przestrzeni nazw oraz konfigurację dodatkowych zakresów UID/GID przed interpretowaniem zmian właściciela.

Opcje uruchomieniowe Podmana pokazują, że keep-id zachowuje mapowanie użytkownika, gdy kontener potrzebuje przewidywalnego dostępu do plików montowanych z hosta.

Nie „naprawiaj” właściciela wyglądającego jak root wewnątrz kontenera, dopóki nie sprawdzisz numerycznego identyfikatora po stronie hosta. Root w przestrzeni nazw i root na hoście nie zawsze oznaczają tę samą tożsamość.

Przetestuj nowy obraz na woluminie testowym

Przed zastąpieniem kontenera produkcyjnego uruchom nowy obraz z zamierzonym UID/GID oraz tymczasowym katalogiem odwzorowującym uprawnienia produkcyjne. Pozwól, aby inicjalizacja podczas uruchamiania utworzyła jeden plik i jeden katalog, a następnie sprawdź ich właściciela po stronie hosta.

Przewodnik Red Hat dotyczący debugowania woluminów rootless pokazuje, że właściciel na hoście wynika z mapowania UID, a sama nazwa użytkownika wyświetlana wewnątrz kontenera nie jest wystarczającym dowodem.

Jeśli test utworzy nieoczekiwane pliki należące do roota lub pliki z przemapowanym właścicielem, wstrzymaj wdrożenie i porównaj użytkownika obrazu, punkt wejścia, przestrzeń nazw oraz ustawienia montowania. Jest to znacznie bezpieczniejsze niż odkrycie zmiany dopiero po tym, jak rekursywna migracja podczas uruchamiania obejmie całe drzewo zdjęć lub bazy danych.

Zweryfikuj grupy dodatkowe i ścieżki z prawem zapisu

Niektóre aplikacje potrzebują podstawowego UID usługi oraz dostępu za pośrednictwem wspólnej grupy multimediów, pobierania lub urządzeń. Zapisz identyfikatory tych grup i przetestuj wszystkie ścieżki z prawem zapisu, nie tylko katalog konfiguracji.

Kubernetes używa jawnych ustawień runAsUser i runAsGroup, ilustrując tę samą zasadę własności w systemie Linux także poza prostym wdrożeniem Docker Compose.

Polityka aktualizacji jest kompletna, gdy nowy obraz tworzy pliki z oczekiwanym właścicielem na hoście we wszystkich ścieżkach trwałych i poprawnie działa po jednokrotnym odtworzeniu kontenera. Powiązany artykuł ZimaSpace dotyczący plików należących do roota po aktualizacji obrazu opisuje procedurę odzyskiwania, jeśli wdrożenie już utworzyło dane należące do roota.