- Pagpapatupad ng prinsipyo ng least privilege upang mabawasan ang attack surface sa host.
- Mas mataas na pamamahala ng UID/GID at mga volume upang maiwasan ang mga conflict sa pahintulot sa pagitan ng container at ng system.
- Mga estratehiya sa pagpapatigas ng imahe gamit ang mga multi-stage build at minimalist na distribusyon.
- Pagkontrol sa mga kakayahan ng Linux at pag-aalis ng privileged mode upang maiwasan ang mga pagtakas ng container.
Sigurado akong nangyari na ito sa iyo: sinusubukan mong mag-set up ng isang container para sa personal na paggamit, na naglalayong magkaroon ng mas mataas na seguridad gamit ang mga unprivileged container , at biglang nakulong sa isang labirinto ng mga error sa pahintulot. Nakakadismaya ang gumugol ng maraming oras sa pag-configure ng mga folder sa home directory ng user para lamang matuklasan na ang container ay hindi maaaring sumulat sa kanila, o kapag nangyari ito, ang mga nagresultang file sa host ay imposibleng pamahalaan dahil ang mga ito ay pagmamay-ari ng isang phantom user.
Ang katotohanan ay, habang pinabilis ng containerization ang paghahatid ng software, binuksan din nito ang pinto sa malalaking panganib. Ayon sa kamakailang datos, ang karamihan sa mga imahe ng produksyon ay may dalang kritikal na mga kahinaan , na ginagawang isang mahalagang haligi ang seguridad. Hindi lamang ito tungkol sa pagpigil sa mga hacker, kundi tungkol sa pag-unawa kung paano gumagana ang paghihiwalay ng proseso upang ang ating imprastraktura ay hindi mapuno ng mga kahinaan.
Pag-unawa sa ecosystem ng seguridad ng lalagyan
Para matigil ang panghuhula gamit ang mga pahintulot, kailangan muna nating malaman kung ano ang ating pinoprotektahan. Ang arkitektura ng isang container ay nahahati sa ilang kritikal na layer. Una, mayroon tayong container image , na siyang orihinal na blueprint; kung ito ay vulnerable, lahat ng instance na iyong ide-deploy ay magiging hindi ligtas. Kaya naman mahalagang gumamit ng mga pinagkakatiwalaang base image at panatilihing updated ang mga ito.
Susunod ay ang runtime , na nagsisilbing tagapamagitan sa pagitan ng host operating system at ng application. Kung luma na ang runtime, ang panganib ng pagtakas ng container ay lubhang tumataas. Dagdag pa rito ang orchestration, tulad ng Kubernetes, kung saan ang role-based access control (RBAC) ang tanging tunay na hadlang laban sa hindi awtorisadong pag-access sa management API.
Hindi natin maaaring kalimutan ang host operating system . Kung ang isang attacker ay nagawang masira ang host kernel, sila ang may hawak ng mga susi sa buong sistema. Malinaw ang rekomendasyon dito: gumamit ng kaunting operating system upang mabawasan ang saklaw ng pag-atake. Panghuli, ang network ang pinakakaraniwang entry point; halos 30% ng mga paglabag ay nangyayari dahil sa mga pagkabigo sa koneksyon, kaya ang network segmentation at TLS/SSL encryption ay kinakailangan.
Ang sakit ng ulo ng mga pahintulot at ang root user
Ang karaniwang problema para sa mga mahilig sa libangan ay ang daloy ng trabaho gamit ang mga volume. Gagawa ka ng folder, i-mount ito, at pagkatapos, boom!, isang error ang lilitaw. tinanggihan ang pahintulotNangyayari ito dahil, bilang default, maraming container ang nagsisimula bilang root. Kapag sinubukan mong pilitin ang UID at GID sa 0 Para maitugma sila sa iyong host user, lumilikha ka ng isang mapanganib na bridge. Kung hindi ka pinapayagan ng container na i-configure ang mga ID na ito, masasayang mo ang isang hapon sa pag-alam kung aling internal user ang ginagamit ng application para magsagawa ng... chown manu-manong
Ang mahusay na solusyon ay ang paglalapat ng prinsipyo ng least privilege . Hindi mo dapat patakbuhin ang anumang bagay bilang root maliban kung talagang kinakailangan. Upang maiwasan ang gulo ng mga file na nilikha ng container na hindi mo maaaring tanggalin sa host, mahalagang i-configure ang Dockerfile gamit ang instruksyong `USER` , na tumutukoy sa isang user na walang mga pribilehiyo bago magsimula ang application.
Kung gumagamit ka ng Podman, ang konsepto ng mga rootless container ay native at lubos na nakakatulong, ngunit nangangailangan ito ng pag-unawa kung paano inima-map ang mga host user sa mga container user. Upang maiwasan ang pagiging mahirap pamahalaan ang mga pahintulot, sa isip ay dapat idinisenyo ang application upang magsulat sa mga partikular na path, at ang volume mapping ay dapat gawin gamit ang aktwal na UID ng user na naglulunsad ng proseso.
Mga estratehiya para sa pagbuo ng mga imaheng nakabaluti
Kung gusto mong ihinto ang pagdurusa, kailangan mong baguhin ang paraan ng pagbuo mo ng iyong mga imahe. Ang isang napakabisang pamamaraan ay ang multi-stage builds . Talaga, gagamit ka ng isang mabibigat na imahe kasama ang lahat ng build tools para makabuo ng binary, at pagkatapos ay kokopyahin lamang ang file na iyon sa isang napakagaan na pangwakas na imahe.
Maaari ka pang gumamit ng Scratch image para sa karagdagang impormasyon . Lumilikha ito ng isang container na walang anumang laman: walang shell, walang package manager, kundi ang iyong application lamang. Ginagawa nitong halos imposible para sa isang attacker na magpatupad ng mga malisyosong command kung sakaling makapasok sila, dahil walang command interpreter na magagamit.
Ang isa pang hakbang sa seguridad ay ang paglilinis ng imahe mula sa anumang binary na may mga pahintulot na setuid o setgid . Ang mga pahintulot na ito ay nagbibigay-daan sa isang file na maisagawa nang may mga pribilehiyo ng may-ari ng file, hindi ng user na naglulunsad nito, na lumilikha ng landas para sa pagtataas ng pribilehiyo . Ang isang simpleng utos na hanapin at alisin ang mga bit na ito habang nasa proseso ng pagbuo ng imahe ay maaaring makatipid sa iyo ng maraming abala.
Ang mga panganib ng privileged mode at ang mga kakayahan ng Linux
Minsan, dahil sa desperasyon kapag hindi natin malutas ang isang problema sa mga pahintulot, natutukso tayong gamitin ang flag na `--privileged` . Kalimutan na lang natin ang paggawa niyan. Binabasag ng privileged mode ang isolation ng container at binibigyan ito ng ganap na access sa mga device ng host. Parang pagbibigay lang ng mga susi ng bahay mo sa isang estranghero dahil lang sa hindi nila alam kung paano buksan ang garden gate.
Sa halip, dapat kang makipaglaro sa Mga kakayahan ng LinuxNagtatalaga ang Docker ng isang hanay ng mga default na pahintulot (tulad ng CAP_CHOWN o CAP_NET_RAW). Kung hindi kailangang manipulahin ng iyong aplikasyon ang network sa mababang antas, ang pinakamatalinong paraan ay alisin ang mga hindi kinakailangang kakayahan at idagdag lamang ang mga mahigpit na kinakailangan ng --cap-add.
Para sa mga namamahala ng mas mahirap na mga kapaligiran, may mga authorization plugin tulad ng opa-docker-authz. Pinapayagan ka nitong maharang ang mga tawag sa API ng Docker daemon at harangan ang anumang pagtatangka na ilunsad ang isang container sa privileged mode, na tinitiyak na walang sinuman, kahit aksidente, ang mag-iiwan ng host na bukas.
Pag-optimize at pagpapanatili ng kapaligiran
Huwag masyadong mag-alala sa laki ng imahe na 5MB kapag gumagamit ng Alpine Linux kung nagdudulot ito ng mga isyu sa compatibility sa mga library. Minsan, mas mainam ang isang medyo mas malaki ngunit matatag na imahe ng Debian, na pamilyar sa team. Gayunpaman, ang mahalaga ay ang pagpapatupad ng awtomatikong vulnerability scanning sa iyong CI/CD pipeline upang matukoy ang mga CVE bago pa man i-produce ang imahe.
Tungkol sa storage, pinipigilan nito ang application sa pagsusulat papunta sa root filesystem. Kino-configure nito ang root filesystem bilang read-only (rootfs) at tinutukoy lamang ang mga partikular na volume para sa data na kailangang i-persist. Hindi lamang ito mas ligtas, kundi pinipilit din nito ang isang mas malinis at estateless na arkitektura , na ginagawang mas madali ang horizontal scaling.
Para sa mga naka-iskedyul na proseso, huwag maglagay ng cron job sa loob ng website container. Ang ginintuang tuntunin ay isang proseso bawat container . Ang pinakamalinis na paraan ay ang paggamit ng imahe ng iyong app upang maglunsad ng isang panandaliang container na nagsasagawa ng gawain at pagkatapos ay sinisira ang sarili nito, o pamahalaan ang cron job mula sa host sa pamamagitan ng pagtawag sa container engine gamit ang mga command.
Ang seguridad ng container ay isang patuloy na proseso na kinabibilangan ng pag-aalis ng root access, paghihigpit sa mga kakayahan ng kernel, at pag-aalis ng mga hindi kinakailangang tool mula sa mga imahe ng container. Sa pamamagitan ng pagsasama-sama ng mga walang pribilehiyong user sa runtime hardening at patuloy na pagsubaybay, nakakamit ang isang kapaligiran kung saan ang functionality ay hindi nakakakompromiso sa integridad ng host system.
Masigasig na manunulat tungkol sa mundo ng mga byte at teknolohiya sa pangkalahatan. Gustung-gusto kong ibahagi ang aking kaalaman sa pamamagitan ng pagsusulat, at iyon ang gagawin ko sa blog na ito, ipakita sa iyo ang lahat ng mga pinaka-kagiliw-giliw na bagay tungkol sa mga gadget, software, hardware, teknolohikal na uso, at higit pa. Ang layunin ko ay tulungan kang mag-navigate sa digital na mundo sa simple at nakakaaliw na paraan.