Сигурен съм, че това ви се е случвало: опитвате се да сглобите контейнер за лична употреба, искате да го направите по-безопасен, използвайки непривилегировани контейнери И изведнъж се озовавате в капан в лабиринт от грешки в разрешенията. Разочароващо е да прекарвате часове в конфигуриране на папки в домашната директория на потребителя, само за да откриете, че контейнерът не може да записва в тях или че когато го прави, получените файлове на хоста са повредени. невъзможно за управление защото принадлежат на фантомен потребител.
Реалността е, че макар контейнеризацията да ускори доставката на софтуер, тя отвори вратата за значителни рискове. Според последните данни, по-голямата част от производствените образи носят [неясно - вероятно „неясно“ или „неясно“] критични уязвимостиТова прави сигурността неотменим стълб. Не става въпрос само за предотвратяване на хакерски атаки, а за разбиране на това как работи системата. изолация на процеса така че нашата инфраструктура да не се превърне в сито.
Разбиране на екосистемата за сигурност на контейнерите
За да спрем да гадаем с разрешенията, първо трябва да знаем какво защитаваме. Архитектурата на контейнера е разделена на няколко критични слоя. Първо, имаме изображение на контейнеракоето е оригиналният план; ако това е уязвимо, всички инстанции, които внедрявате, ще бъдат несигурни. Ето защо е жизненоважно да се използва надеждни базови изображения и ги поддържайте актуални.
Тогава време за изпълнениекойто действа като арбитър между операционната система на хоста и приложението. Ако средата за изпълнение е остаряла, рискът от бягство от контейнер се увеличава драстично. Към това трябва да добавим оркестрацията, като например Kubernetes, където контрол на достъпа, базиран на роли (RBAC) Това е единствената реална бариера срещу неоторизиран достъп до API за управление.
Не можем да забравим хост операционна системаАко атакуващ успее да компрометира ядрото на хоста, той държи ключовете за целия домейн. Препоръката тук е ясна: използвайте минимална операционна система за да се намали повърхността за атака. И накрая, мрежата е най-честата входна точка; почти 30% от нарушенията се дължат на проблеми с връзката, така че сегментиране на мрежата и TLS/SSL криптиране Те са задължителни.
Главоболието с разрешенията и root потребителя
Типичният проблем за любителите е работният процес с томове. Създавате папка, монтирате я и след това, бум!, грешка. разрешение отказаноТова се случва, защото по подразбиране много контейнери стартират като root. Когато се опитате да принудите UID и GID при 0 За да ги настроите да съответстват на потребителя на вашия хост, създавате опасен мост. Ако контейнерът не ви позволява да конфигурирате тези идентификатори, ще загубите цял следобед, опитвайки се да разберете кой вътрешен потребител използва приложението, за да извърши... chown ръководство.
Ефективното решение е да се приложи принцип на най-малката привилегияНе бива да стартирате нищо като root, освен ако не е абсолютно необходимо. За да решите проблема с файловете, създадени от контейнери, които не можете да изтриете на хоста, е важно да конфигурирате Dockerfile със следната инструкция: ПОТРЕБИТЕЛЯ, дефиниране на потребител без привилегии преди стартиране на приложението.
Ако използвате Podman, концепцията за контейнери без корени Той е вграден и много полезен, но изисква да разберете как потребителите на хоста са съпоставени с потребителите на контейнера. За да се предотврати излизането на разрешенията извън контрол, в идеалния случай приложението трябва да е проектирано да записва в специфични маршрути и че картографиране на обема Това се прави, като се има предвид реалният UID на потребителя, стартиращ процеса.
Стратегии за изграждане на бронирани изображения
Ако искате да спрете да страдате, трябва да промените начина, по който изграждате образите си. Една брутално ефективна техника е... многоетапни конструкцииПо принцип използвате тежък образ с всички инструменти за изграждане, за да генерирате двоичния файл, и след това копирате само този файл в окончателното изображение. изключително лек.
Можете дори да стигнете по-далеч, използвайки изображението надраскатТова създава контейнер, който няма абсолютно нищо: нито обвивка, нито мениджър на пакети, а само вашето приложение. Това прави практически невъзможно за атакуващия да изпълни злонамерени команди, ако успее да влезе, тъй като Няма интерпретатор на команди на разположение.
Друга мярка за сигурност е почистването на образа на всеки двоичен файл с разрешения. setuid или setgidТези разрешения позволяват файлът да бъде изпълнен с привилегиите на собственика на файла, а не на потребителя, който го стартира, което е магистрала за... ескалация на привилегиитеЕдна проста команда за търсене и премахване на тези части по време на изграждане на изображение може да ви спести много проблеми.
Опасностите от привилегирования режим и възможностите на Linux
Понякога, отчаяни от невъзможността да решим проблем с разрешенията, изпадаме в изкушението да използваме флага –привилегированЗабравете за това. Привилегированият режим нарушава изолацията на контейнера и ви дава пълен достъп до устройствата на хоста. Все едно да дадете ключовете от къщата си на непознат, само защото не е знаел как да отвори градинската порта.
Вместо това, трябва да си играете с Възможности на LinuxDocker задава набор от разрешения по подразбиране (като CAP_CHOWN или CAP_NET_RAW). Ако приложението ви не е необходимо да манипулира мрежата на ниско ниво, най-умният подход е елиминирайте ненужните възможности и добавете само тези, които са строго изисквани от --cap-add.
За тези, които управляват по-сериозни среди, има плъгини за оторизация като например opa-docker-authz. Те позволяват прихващане на повиквания към API на Docker демона и блокиране на всеки опит за стартиране на контейнер в привилегирован режим, като гарантират, че никой, дори по погрешка, няма да остави вратата отворена към хоста.
Оптимизация и поддръжка на околната среда
Не се вторачвайте в размера на образа от 5MB, когато използвате Alpine Linux, ако това причинява проблеми със съвместимостта с библиотеките. Понякога е за предпочитане малко по-голям образ на Debian. стабилизиран и известен от екипа. От решаващо значение е прилагането на сканиране на уязвимости Автоматизиран CI/CD конвейер за откриване на CVE, преди изображението да достигне производствения процес.
Що се отнася до паметта, това предотвратява записването на данни в главната файлова система на приложението. Конфигурирайте файлова система само за четене (rootfs) и определя специфични томове само за данните, които трябва да се съхраняват. Това е не само по-сигурно, но и налага по-чиста архитектура и без имуществоулесняване на хоризонталното мащабиране.
За планирани процеси, не поставяйте cron задача в контейнера на уебсайта. Златното правило е един процес на контейнерНай-чистият подход е да използвате образа на приложението си, за да стартирате ефимерен контейнер, който изпълнява задачата и след това се самоунищожава, или да управлявате cron от хоста, като извикате двигателя на контейнера с помощта на команди.
Сигурността на контейнерите е непрекъснат процес, който включва елиминиране на root достъпа, ограничаване на възможностите на ядрото и премахване на ненужни инструменти от образите на контейнерите. Чрез комбиниране на непривилегировани потребители с укрепване по време на изпълнение и постоянно наблюдение се постига среда, в която функционалността не компрометира целостта на хост системата.
Страстен писател за света на байтовете и технологиите като цяло. Обичам да споделям знанията си чрез писане и това е, което ще направя в този блог, ще ви покажа всички най-интересни неща за джаджи, софтуер, хардуер, технологични тенденции и много други. Моята цел е да ви помогна да се ориентирате в дигиталния свят по лесен и забавен начин.