Вывучаем (адсутную) бяспеку тыповых усталёвак Docker і Kubernetes

Вывучаем (адсутную) бяспеку тыповых усталёвак Docker і Kubernetes
Я працую ў IT больш за 20 гадоў, але неяк рукі не даходзілі да кантэйнераў. У тэорыі я разумеў, як яны ўладкованыя і як працуюць. Але паколькі я ніколі з імі не сутыкаўся на практыцы я не быў упэўнены ў тым, як менавіта круцяцца-круцяцца ў іх шасцярэнькі пад капотам.

Акрамя таго, я быў без паняцця аб тым, як у іх з бяспекай. Але зноў жа, тэорыя гучыць прыгожа, а старая песня "пры росце бяспекі падае зручнасць выкарыстання" засела ў мяне ў галаве. Так што я падумаў, што раз усё так лёгка рабіць з кантэйнерамі, то бяспека там ніжэй ліштвы. Як аказалася, я меў рацыю.

Для хуткага старту я запісаўся на курсы Black Hat 2020 пад назвай «З бруду ў князі: пранікненне і абарона акружэнняў Docker Swarm і Kubernetes.

Курс, які праводзілі Sheila A. Berta і Sol Ozzan, адразу ж пачаўся з апісання таго, як працуюць кантэйнеры Docker, а таксама які шлях яны праходзяць пры разгортванні ў Kubernetes. Гэта быў цалкам практычны занятак - студэнты павінны былі папярэдне перад заняткамі ўсталяваць Docker і microk8s на свае машыны - выдатны спосаб убачыць узаемадзеянне інструментаў паміж сабой, знайсці слабыя месцы і, што самае важнае, паспрабаваць іх блакаваць.

На жаль хоць курсы і абяцалі стаць "князем" праз два дні, я адчуваў, што ўсё толькі пачынаецца, і мне яшчэ трэба шмат чаму навучыцца.

Вывучаем (адсутную) бяспеку тыповых усталёвак Docker і Kubernetes

Перш чым акунуцца ў мае высокія назіранні, важна растлумачыць, што такое кантэйнер. У свеце распрацоўкі лічыцца нармальнай сітуацыя, калі код, напісаны на вашай асабістай машыне, працуе ідэальна, але пры спробе запусціць яго дзесьці на серверы - ён проста не працуе. Кантэйнеры спрабуюць пераадолець гэтую праблему падаючы аўтаномныя машыны, якія вы можаце лёгка пераносіць з аднаго сервера на іншы, ведаючы, што яны будуць заўсёды працаваць. Як відаць з імя, яны ўтрымоўваюць код, бібліятэкі і іншае ПЗ, патрэбнае для працы. 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 замест зменных асяроддзя: Сакрэты ёсць прыкладна з 2017 года. Хоць гэта і небяспечна, але ўсё ж лепш, чым зменныя асяроддзі для перадачы сакрэтных дадзеных у кантэйнер.

Калі артыкул выклікала ў вас цікавасць да кантэйнераў - можна дастаткова лёгка ўсталяваць Docker або microk8s (невялікая версія Kubernetes). Тут ёсць інструкцыі па ўсталёўцы Docker для Linux і MacOS, а тут - інструкцыі па ўстаноўцы microk8s для Windows, Linux і MacOS.

Пасля ўстаноўкі можна прайсці гэта кіраўніцтва па хуткім старце ад Docker, падобны варыянт прапануецца і для microk8s.

Калі ёсць жаданне ці неабходнасць прайсці комплексны курс па Docker, у якім спікеры-практыкі разбіраюць усе яго прылады: ад асноўных абстракцый да параметраў сеткі, нюансаў працы з рознымі АС і мовамі праграмавання, то паспрабуйце.Відэакурс па Docker». Вы пазнаёміцеся з тэхналогіяй і зразумееце, дзе і як лепш выкарыстоўваць Docker. А заадно атрымаеце best practice кейсы - лепш навучацца ў бяспецы і з падтрымкай практыкаў на гісторыях аб граблях, чым асабіста на саміх граблях з шыпаванымі ручкамі.

Крыніца: habr.com

Дадаць каментар