Dlaczego tryb uprzywilejowany jest szerszy, niż potrzebuje VPN

Kontener nie chciał otworzyć swojego tunelu, więc dodano uprzywilejowaną flagę i teraz to działa. Ten ciąg ustalił tylko, że brakowało co najmniej jednego uprawnienia, i nic nie mówi o tym którego. Tryb uprzywilejowany daje zestaw uprawnień i dostęp do urządzeń znacznie szerszy, niż potrzebuje interfejs tunelu.

Co flaga naprawdę zmienia

Uprzywilejowany kontener otrzymuje szerokie uprawnienia i dostęp do urządzeń hosta, co jest znacznie większym nadaniem, niż wymaga ścieżka sieciowa. Dokładny zestaw dokumentuje środowisko uruchomieniowe, a nie ustala tradycja, i dokumentacja Dockera dotycząca uruchamiania kontenerów opisuje dostępne opcje uprawnień. Jedno przeczytanie wystarczy, by zobaczyć, że tunel to mała część całości.

Dwa węższe wymagania pokrywają większość kontenerów VPN. Konfiguracja interfejsu wymaga uprawnienia do administracji siecią, a otwarcie urządzenia tunelu wymaga dostępu do dokładnie tego węzła urządzenia. To osobne nadania, i nawet oba razem są węższe niż opcja zbiorcza. Reszta zestawu uprzywilejowanego nie ma nic wspólnego z tunelem. Istnieje dla obciążeń, które naprawdę potrzebują dostępu na poziomie hosta, a kontener VPN zwykle nie jest jednym z nich.

Dopasuj każdy błąd do jednego warunku

Komunikat o błędzie mówi, którego wymogu brakuje, jeśli przeczytasz go przed wyciszeniem. Komunikat o węźle urządzenia nazywa urządzenie, komunikat o niedozwolonej operacji nazywa uprawnienie, a komunikat o module lub sysctl nazywa wsparcie jądra. Każdy z nich ma inne rozwiązanie, i tylko jeden z nich jest uprawnieniem.

Brakujący plik konfiguracyjny pozostaje brakujący po nadaniu wszystkich uprawnień, dlatego tryb uprzywilejowany czasem nie zmienia zupełnie nic. Kontener startuje, tunel nadal zawodzi, a prawdziwy błąd nigdy nie dotyczył uprawnień. Wsparcie jądra to trzeci przypadek i najłatwiejszy do błędnego odczytania. Moduł, który nie jest załadowany na hoście, nie może zostać załadowany z wnętrza nieuprzywilejowanego kontenera, a nadanie większej liczby uprawnień wewnątrz kontenera nie zmienia stanu hosta.

Sprawdź wymóg, nie objaw

Zacznij od minimalnego wywołania, które dokumentuje obraz, uruchom je i zachowaj dokładny tekst błędu. Następnie dodawaj jedno nadanie naraz i notuj, które dodanie zmieniło wynik.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tun

Kontener, który widzi urządzenie i ma uprawnienie, ale nadal zawodzi, mówi ci, że problem jest gdzie indziej. To użyteczny wynik, a tryb uprzywilejowany by go ukrył.

Sprawdź także uprawnienia urządzenia na hoście, ponieważ poprawnie nadany węzeł urządzenia z niewłaściwym właścicielem grupy daje ten sam błąd co brakujące nadanie.

Zapisz najwęższe działające nadanie

Zapisz każde urządzenie i uprawnienie, których potrzebuje wdrożenie, wraz z błędem, który je uzasadnił. Ten zapis pozwala następnej osobie bezpiecznie coś usunąć, i o niego poprosi audytor, gdy kontener zostanie zgłoszony jako uprzywilejowany.

Przejrzyj też otaczający kontekst, ponieważ sieć hosta, montowania hosta i opcje środowiska uruchomieniowego mogą każde poszerzyć wpływ nadania. Izolowane wywołanie laboratoryjne, które łączy je wszystkie, nie jest konfiguracją produkcyjną, jakkolwiek dobrze działało. Przetestuj aplikację, jej zachowanie w DNS i awarię tunelu, zanim uznasz wdrożenie za zakończone. Pozwolenie na utworzenie interfejsu nie jest polityką wyjścia, a kontener, który potrafi idealnie tunelować, nadal kieruje wszystko, co wysyła aplikacja.