Защо привилегированият режим е по-широк, отколкото е нужно на VPN

Контейнерът не искаше да отвори своя тунел, затова беше добавен привилегированият флаг и сега работи. Тази последователност установи само че липсва поне едно разрешение и не казва нищо за това кое. Привилегированият режим дава набор от възможности и достъп до устройства, много по-широк от необходимото за един тунелен интерфейс.

Какво всъщност променя флагът

Привилегированият контейнер получава широки възможности и достъп до устройства на хоста, което е много по-голямо разрешение, отколкото изисква мрежовият път. Точният набор се документира от средата за изпълнение, а не се определя от предания, и документацията на Docker за стартиране на контейнери описва наличните опции за привилегии. Едно прочитане е достатъчно, за да се види, че тунелирането е малка част от цялото.

Две по-тесни изисквания покриват повечето VPN контейнери. Конфигурирането на интерфейс изисква възможността за администриране на мрежата, а отварянето на тунелното устройство изисква достъп до точно този възел на устройството. Това са отделни разрешения и дори заедно те са по-тесни от общата опция. Останалата част от привилегирования набор няма нищо общо с тунела. Тя съществува за натоварвания, които наистина се нуждаят от достъп на ниво хост, а един VPN контейнер обикновено не е едно от тях.

Съпоставете всяка грешка с едно предварително условие

Съобщението за грешка ви казва кое предварително условие липсва, ако го прочетете, преди да го потиснете. Съобщение за възел на устройство назовава устройството, съобщение за операция, която не е разрешена, назовава възможност, а съобщение за модул или sysctl назовава поддръжка на ядрото. Всяко от тях има различно решение и само едно от тях е възможност.

Липсващият конфигурационен файл остава липсващ след предоставянето на всяка възможност, поради което привилегированият режим понякога не променя нищо. Контейнерът стартира, тунелът все още се проваля, а истинската грешка никога не е била за разрешения. Поддръжката на ядрото е третият случай и най-лесно се разчита погрешно. Модул, който не е зареден на хоста, не може да бъде зареден отвътре в непривилегирован контейнер, а предоставянето на повече възможности вътре в контейнера не променя състоянието на хоста.

Проверете изискването, а не симптома

Започнете с минималното извикване, което изображението документира, изпълнете го и запазете точния текст на грешката. След това добавяйте по едно разрешение наведнъж и отбелязвайте кое добавяне промени резултата.

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

Контейнер, който вижда устройството и притежава възможността, но все още се проваля, ви казва, че проблемът е другаде. Това е полезен резултат и привилегированият режим би го скрил.

Проверете и разрешенията за устройството на хоста, защото правилно предоставен възел на устройство с грешна собственост на групата дава същата грешка като липсващо разрешение.

Запишете най-тясното разрешение, което работи

Запишете всяко устройство и възможност, от които се нуждае разгръщането, заедно с грешката, която ги е оправдала. Този запис е това, което позволява на следващия човек безопасно да премахне нещо, и това е, което одиторът ще поиска, когато контейнер бъде докладван като привилегирован.

Прегледайте и околния контекст, защото мрежата на хоста, монтиранията на хоста и опциите на средата за изпълнение могат всяко да разшири въздействието на дадено разрешение. Изолирано лабораторно извикване, което комбинира всички тях, не е производствена конфигурация, колкото и добре да е работило. Тествайте приложението, поведението му в DNS и отказ на тунела, преди да обявите разгръщането за завършено. Разрешението за създаване на интерфейс не е политика за изход, а контейнер, който тунелира перфектно, все още маршрутизира всичко, което приложението изпрати.