Работя в IT над 20 години, не ми оставаше време да се запозная с контейнерите. В теоретичен аспект разбирах как работят, но в практиката никога не бях имал контакти с тях — не бях сигурен как точно функционират нещата под капака.
Освен това нямаше ми представа как стоят нещата с безопасността. Но отново, теорията звучи прекрасно, а старата песен "с увеличаването на безопасността удобството на употреба намалява" ми беше заседнала в ума. Помислих си, че ако всичко е толкова лесно с контейнерите, то безопасността ще е на много ниско ниво. Както се оказа, бях прав.
За бърз старт се записах на курс 2020 с наименование "».
Курсът, провеждан от Sheila A. Berta и Sol Ozzan, веднага започна с обяснение как работят контейнерите Docker и какъв маршрут следват при разгръщането си в Kubernetes. Това беше напълно практическо занятие — студентите трябваше да инсталират Docker и microk8s на своите машини преди занятията — отличен начин да видят взаимодействието между инструментите, да открият слабости и, най-важното, да опитат да ги блокират.
За съжаление, макар курсовете и обещаха да станат "княза" след два дни, усещах, че всичко само започва и все още имам много да уча.
Преди да се потопя в моите високи наблюдения, е важно да обясня какво е контейнер. В света на разработката е нормално, кодът, написан на личния компютър, да работи перфектно, но когато опитате да го стартирате на сървър, той просто не работи. Контейнерите се опитват да преодолеят този проблем, предлагайки автономни машини, които лесно можете да прехвърляте от един сървър на друг, знаейки, че те винаги ще работят. Както показва името, те съдържат код, библиотеки и друг софтуер, необходим за функционирането си. Kubernetes, от друга страна, е . В принципе, с него можете безпроблемно да управлявате стотици или хиляди различни контейнери.
По-долу следват някои мои изводи от гледна точка на червената и синята команда.
Червената команда
Повечето от съдържанието в контейнерите се стартира под root: това означава, че ако компрометираш контейнера, ще получиш пълен достъп до него. Това прави последващите стъпки значително по-лесни.
Монтирането на docker.sock в контейнера е опасно: ако получиш root в контейнера и също така инсталираш Docker в контейнера, който има сокета Docker (\/var\/run\/docker.sock), имаш потенциална възможност да изследваш целия клъстер, включително достъп до всякакъв друг контейнер. Такъв достъп не може да бъде предотвратен нито чрез мрежова изолация, нито по друг начин.
Променливите на средата често съдържат секретни данни: в повечето случаи хората изпращат пароли в контейнер с помощта на обикновени променливи на средата. Така че, ако имаш достъп до акаунта, можеш да надзърнеш тези променливи на средата с цел да разшириш правата си.
Docker API може да предостави много информация: Docker API, при настройка по подразбиране, работи без авторизация и може да предоставя много информация. Използвайки Shodan, лесно можеш да намериш списък с отворени портове, след това да получиш подробна информация за клъстера — и да преминеш към неговото пълно завладяване. TrendMicro написаха интересна статия за това .
Синята команда
Не стартирайте съдържанието на контейнерите под root: въпреки че е по-лесно да стартиране под root, не трябва да го правиш. Вместо това стартирайте приложенията с понижени права, задавайки uid или с помощта на параметър —user при работа с CLI, или указвайки USER в Dockerfile.
Не позволявайте инсталация на програми в контейнерите: почти всяка атака започва с инсталирането на нещо. Започвайки от nmap и завършвайки с ifconfig и самия Docker (вътре в контейнера), инсталирането на каквото и да е в контейнера е било обичайно. Поради тази причина винаги трябва да блокираш всички неизползвани портове. Това също помага за предотвратяване на предаването на управленски команди, когато машината ти бъде заразена. Освен предотвратяването на инсталацията на програми, трябва да се увериш, че в самия контейнер е инсталиран минимален брой приложения, необходими за изпълнение на задачата.
Защитавайте docker.sock: трябва да го защитавате, тъй като през този сокет се обработва връзката между контейнера и клъстера. Тъй като не искам да навлизам в детайлите в тази статия, прочетете , какво може да се случи и как да блокираш всичко това.
Използвайте секретите на Docker вместо променливи за среда: Има секрети . Въпреки че това не е безопасно, е все пак по-добре от променливите за среда за предаване на секретни данни в контейнер.
Ако статията е предизвикала интереса ви към контейнерите — можете да инсталирате Docker или microk8s (по-малка версия на Kubernetes) достатъчно лесно. има инструкции за инсталиране на Docker за Linux и MacOS, а — инструкции за инсталиране на microk8s за Windows, Linux и MacOS.
След инсталирането можете да преминете към от Docker, подобен вариант и за microk8s.
Ако имате желание или необходимост да преминете през цялостен курс по Docker, в който практикуващи лектори разглеждат всички негови инструменти: от основните абстракции до мрежовите параметри, нюансите на работа с различни операционни системи и програмни езици, опитайте "". Ще се запознаете с технологията и ще разберете къде и как е най-добре да използвате Docker. А заедно ще получите случаи на best practice — по-добре е да се учите в безопасност и с подкрепата на практикуващи, отколкото да настъпите сами на гърчета с шиповани дръжки.
Източник: habr.com
