ຮູບພາບ Docker ທີ່ເປັນອັນຕະລາຍເຂົ້າສູ່ Trusted ໄດ້ແນວໃດ Pipelineບໍ່ຮູ້ຕົວ
ການລົງທະບຽນ Docker ແມ່ນຫົວໃຈຂອງຂະບວນການເຮັດວຽກທີ່ມີຕູ້ຄອນເທນເນີ. ມັນເກັບຮັກສາ, ແຈກຢາຍ ແລະ ເວີຊັນຮູບພາບຕ່າງໆ. ແຕ່ຖ້າປ່ອຍໃຫ້ເປີດເຜີຍ ຫຼື ຖືກຄວບຄຸມຢ່າງວ່າງໆ, ຜູ້ໂຈມຕີສາມາດສັກຮູບພາບ Docker ທີ່ເປັນອັນຕະລາຍໂດຍກົງເຂົ້າໄປໃນ pipelines.
ມັນເກີດຂຶ້ນແນວໃດ:
- ນະໂຍບາຍການດຶງແບບເປີດ: A pipeline ດຶງ myorg/base: ລ່າສຸດ ໂດຍບໍ່ໄດ້ກວດສອບແຫຼ່ງຂໍ້ມູນ ຫຼື ຄວາມສົມບູນ
- ບັນຊີທີ່ຖືກລະເມີດຜູ້ໂຈມຕີສາມາດເຂົ້າເຖິງທະບຽນຕູ້ຄອນເທນເນີ ແລະ ປ່ຽນແທນຮູບພາບທີ່ເຊື່ອຖືໄດ້
- typosquattingນັກພັດທະນາດຶງຜິດພາດ myorg-base ແທນທີ່ myorg/base
ຕົວຢ່າງໃນວຽກ GitLab CI:
ທີ່ນີ້, ໂນດ: ລ່າສຸດ ສາມາດປ່ຽນແປງໄດ້ພາຍໃນຄືນດຽວ. ຖ້າຜູ້ໂຈມຕີສາມາດເຜີຍແຜ່ ເປັນພິດ ຫຼ້າສຸດ ຮູບພາບເລັກນ້ອຍ, ມັນຖືກດຶງໂດຍອັດຕະໂນມັດ. ລຸ້ນທີ່ປອດໄພ:
ການລັອກຮູບພາບໃຫ້ເປັນເວີຊັນສະເພາະຈະປ້ອງກັນການເລື່ອນໄປແບບງຽບໆ. ຮູບພາບ Docker ທີ່ເປັນອັນຕະລາຍສາມາດເຂົ້າໄປໄດ້ກໍ່ຕໍ່ເມື່ອທ່ານໄວ້ວາງໃຈ "ລ່າສຸດ" ຢ່າງບໍ່ຮູ້ຕົວເທົ່ານັ້ນ.
ເປັນຫຍັງ Docker Registry ທັງໝົດຈຶ່ງບໍ່ປອດໄພໂດຍຄ່າເລີ່ມຕົ້ນ
ບໍ່ແມ່ນທຸກໆ Docker registry ບັງຄັບໃຊ້ຄ່າເລີ່ມຕົ້ນທີ່ເຂັ້ມແຂງ. ນັກພັດທະນາມັກຈະໄວ້ວາງໃຈແຫຼ່ງຂໍ້ມູນສາທາລະນະໂດຍບໍ່ໄດ້ຢືນຢັນຕົ້ນກຳເນີດ. ຄວາມສ່ຽງລວມມີ:
- ການດຶງທີ່ບໍ່ໄດ້ກວດສອບຄວາມຖືກຕ້ອງ ຈາກທະບຽນຕູ້ຄອນເທນເນີສາທາລະນະ
- ຮູບພາບທີ່ບໍ່ມີລາຍເຊັນ ໂດຍບໍ່ມີຫຼັກຖານວ່າໃຜເປັນຜູ້ສ້າງພວກມັນ
- ການລົງທະບຽນຂອງພາກສ່ວນທີສາມ ດ້ວຍນະໂຍບາຍທີ່ອ່ອນແອ, ເຊິ່ງນຳໄປສູ່ການດັດແປງຮູບພາບພື້ນຖານ
ຕົວຢ່າງຂອງພຶດຕິກຳທີ່ບໍ່ປອດໄພ:
ອັນຕະລາຍ: ເຈົ້າບໍ່ຮູ້ວ່າໃຜສ້າງມັນ, ເວລາໃດ, ຫຼື ມີຫຍັງຢູ່ພາຍໃນ. ວິທີການທີ່ປອດໄພກວ່າ:
ກວດສອບຜູ້ເຜີຍແຜ່ຢູ່ສະເໝີ, ກວດສອບຄວາມສົມບູນຂອງລະຫັດລັບ, ແລະ ເລືອກໃຊ້ທະບຽນທາງການທີ່ເຊື່ອຖືໄດ້. ການສົມມຸດວ່າທະບຽນ Docker ແຕ່ລະອັນປອດໄພຕາມຄ່າເລີ່ມຕົ້ນຈະສ້າງຈຸດບອດຂອງລະບົບຕ່ອງໂສ້ການສະໜອງ.
ການບັງຄັບໃຊ້ແຫຼ່ງທີ່ມາຂອງຮູບພາບດ້ວຍລາຍເຊັນ ແລະ ການຄວບຄຸມການເຂົ້າເຖິງ
ເພື່ອປ້ອງກັນຮູບພາບ Docker ທີ່ເປັນອັນຕະລາຍ, ທີມງານ DevSecOps ຕ້ອງບັງຄັບໃຊ້ແຫຼ່ງທີ່ມາຂອງຮູບພາບ. ນີ້ໝາຍເຖິງການກວດສອບຄວາມຖືກຕ້ອງກ່ອນທີ່ຮູບພາບໃດໆຈະເຂົ້າສູ່ການພັດທະນາ, ການທົດສອບ, ຫຼືການຜະລິດ. ການປະຕິບັດທີ່ດີທີ່ສຸດລວມມີ:
- ການເຊັນຮູບພາບໃຊ້ Docker Content Trust ຫຼື Sigstore ເພື່ອເຊັນຮູບພາບ
- ນະໂຍບາຍຂອງ RBACຈຳກັດຜູ້ທີ່ສາມາດຍູ້ ຫຼື ດຶງອອກຈາກທະບຽນຕູ້ຄອນເທນເນີໄດ້
ການຢັ້ງຢືນຕ້ອງການ metadata ທີ່ພິສູດວ່າຮູບພາບຖືກສ້າງຂຶ້ນແນວໃດ ແລະ ຢູ່ໃສ. ຕົວຢ່າງກັບ Docker Content Trust:
ເມື່ອເປີດໃຊ້ຄວາມໄວ້ວາງໃຈ, ຮູບພາບທີ່ບໍ່ໄດ້ເຊັນຈະຖືກປະຕິເສດ. ເມື່ອລວມກັບ RBAC, ສິ່ງນີ້ຈະຊ່ວຍປ້ອງກັນບໍ່ໃຫ້ຜູ້ໃຊ້ທີ່ຫຼອກລວງໃສ່ການສ້າງ build ທີ່ຖືກພິດເຂົ້າໄປໃນ Docker registry ຂອງທ່ານ.
ການກວດສອບຄວາມປອດໄພຂອງຮູບພາບໂດຍອັດຕະໂນມັດ CI/CD Pipelines
ການຢັ້ງຢືນດ້ວຍຕົນເອງບໍ່ສາມາດຂະຫຍາຍໄດ້. ການກວດສອບຄວາມປອດໄພຕ້ອງເປັນອັດຕະໂນມັດເພື່ອປ້ອງກັນຮູບພາບ Docker ທີ່ເປັນອັນຕະລາຍກ່ອນທີ່ມັນຈະແຜ່ລາມ.
ເຕັກນິກ:
- ເຄື່ອງຈັກນະໂຍບາຍເຄື່ອງມືຕ່າງໆເຊັ່ນ OPA Gatekeeper ບັງຄັບໃຊ້ການລົງທະບຽນ ແລະ ແທັກທີ່ອະນຸຍາດ
- ເຄື່ອງສະແກນຊ່ອງໂຫວ່: ວິເຄາະຮູບພາບໂດຍອັດຕະໂນມັດສຳລັບ CVE ທີ່ຮູ້ຈັກ
- Pipeline ຜູ້ປົກຄອງ: ບລັອກການນຳໃຊ້ຖ້າຮູບພາບບໍ່ຕອບສະໜອງຄວາມຕ້ອງການຂອງລາຍເຊັນ ຫຼື ການສະແກນ.
CI/CD ຍົກຕົວຢ່າງ
ລາຍການກວດສອບຂະໜາດນ້ອຍສຳລັບນັກພັດທະນາ (CI/CD ຄວາມປອດໄພຂອງທະບຽນ)
- ບໍ່ເຄີຍໃຊ້ ຫຼ້າສຸດ ແທັກໃນການຜະລິດ pipelines
- ດຶງຂໍ້ມູນຈາກທະບຽນ Docker ທີ່ເຊື່ອຖືໄດ້ເທົ່ານັ້ນ
- ບັງຄັບໃຊ້ການເຊັນລະຫັດລັບສຳລັບທຸກໆຮູບພາບ
- ສະແກນຮູບພາບໃນເວລາສ້າງ ແລະ ນຳໃຊ້
- ບລັອກຮູບພາບທີ່ບໍ່ໄດ້ເຊັນ ຫຼື ບໍ່ໄດ້ສະແກນໂດຍອັດຕະໂນມັດ
ການກວດສອບແບບອັດຕະໂນມັດຮັບປະກັນວ່າຜູ້ໂຈມຕີບໍ່ສາມາດລັກລອບເອົາຮູບພາບ Docker ທີ່ເປັນອັນຕະລາຍເຂົ້າມາໄດ້ໃນຂະນະທີ່ນັກພັດທະນາກຳລັງຂຽນໂປຣແກຣມຢ່າງລະມັດລະວັງ.
ການສ້າງຍຸດທະສາດ Docker Registry ທີ່ປອດໄພດ້ວຍຫຼັກການ DevSecOps
ການລົງທະບຽນ Docker ທີ່ແຂງແກ່ນແມ່ນຫຼາຍກວ່າລະບົບເກັບຮັກສາ; ມັນເປັນສ່ວນໜຶ່ງຂອງຂອບເຂດຄວາມປອດໄພຂອງທ່ານ. ການປະຕິບັດຫຼັກ:
- ຈຳກັດການດຳເນີນການ push/pull ສະເພາະບັນຊີທີ່ເຊື່ອຖືໄດ້ເທົ່ານັ້ນ
- ແບ່ງສ່ວນລີຈິສຕຣີຕາມສະພາບແວດລ້ອມ (dev, staging, prod)
- ເປີດໃຊ້ການບັນທຶກການກວດສອບສຳລັບທຸກໆການກະທຳຂອງລີຈິດສະຕິກ
- ທຳຄວາມສະອາດຮູບພາບທີ່ບໍ່ໄດ້ໃຊ້ເປັນປະຈຳເພື່ອຫຼຸດຜ່ອນໜ້າດິນທີ່ຖືກໂຈມຕີ
ການລົງທະບຽນຕູ້ຄອນເທນເນີທີ່ສອດຄ່ອງກັບ ຫຼັກການ DevSecOps ຮັບປະກັນວ່າທຸກໆຮູບພາບທີ່ເຄື່ອນທີ່ຜ່ານ pipeline ຖືກຄວບຄຸມ, ສາມາດຕິດຕາມໄດ້, ແລະ ຮັບປະກັນຄວາມປອດໄພ.
ວິທີແກ້ໄຂທີ່ຄ້າຍຄື ຊີເກນີ ເສີມຂະຫຍາຍສິ່ງນີ້ໂດຍການຕິດຕາມກວດກາການລົງທະບຽນຢ່າງຕໍ່ເນື່ອງ ແລະ pipelineສຳລັບຮູບພາບທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ ຫຼື ມີການດັດແປງ. ພວກເຂົາບັງຄັບໃຊ້ guardrails ສະນັ້ນມີພຽງແຕ່ຮູບພາບທີ່ໄດ້ຮັບການຢັ້ງຢືນເທົ່ານັ້ນທີ່ຈະນຳໃຊ້ໄດ້.
ການລັອກ Docker Registry ຂອງທ່ານ
ການລົງທະບຽນ Docker ຂອງທ່ານແມ່ນສ່ວນໜຶ່ງຂອງໜ້າດິນໂຈມຕີຂອງທ່ານ. ຖ້າຜູ້ໂຈມຕີສົ່ງຮູບພາບ Docker ທີ່ເປັນອັນຕະລາຍເຂົ້າມາ, CI/CD pipeline ສາມາດກາຍເປັນລະບົບການຈັດສົ່ງສຳລັບພາລະຂົນສົ່ງຂອງເຂົາເຈົ້າ. ສິ່ງສຳຄັນສຳລັບນັກພັດທະນາແມ່ນຈະແຈ້ງ:
- ຢ່າໄວ້ວາງໃຈຄ່າເລີ່ມຕົ້ນ: ກວດສອບຄວາມຖືກຕ້ອງຂອງທຸກໆແຫຼ່ງຮູບພາບ
- ປັກໝຸດເວີຊັນ ແລະ ຫຼີກລ່ຽງ ຫຼ້າສຸດ
- ສະແກນອັດຕະໂນມັດ ແລະ ບັງຄັບໃຊ້ນະໂຍບາຍການເຊັນ
- ປະຕິບັດຕໍ່ການລົງທະບຽນຕູ້ຄອນເທນເນີຂອງທ່ານຄືກັບໂຄງສ້າງພື້ນຖານທີ່ສຳຄັນ
ການລວມຄວາມປອດໄພຂອງການລົງທະບຽນເຂົ້າໃນຂະບວນການເຮັດວຽກ DevSecOps ຂອງທ່ານຊ່ວຍຫຼຸດຜ່ອນຄວາມສ່ຽງຂອງການສ້າງທີ່ເປັນພິດທີ່ແຜ່ລາມໄປທົ່ວສະພາບແວດລ້ອມຢ່າງງຽບໆ. ເຄື່ອງມືຕ່າງໆເຊັ່ນ Xygeni ເຮັດໃຫ້ສິ່ງນີ້ເປັນປະໂຫຍດໂດຍການໃຫ້ຄວາມເຂົ້າໃຈກ່ຽວກັບຄວາມສ່ຽງຂອງການລົງທະບຽນທີ່ເຊື່ອງໄວ້, ການບັງຄັບໃຊ້ນະໂຍບາຍ, ແລະການກວດຫາຮູບພາບທີ່ຖືກດັດແປງກ່ອນທີ່ພວກມັນຈະເປີດໃຊ້ງານ. ການລັອກ registry Docker ຂອງທ່ານບໍ່ພຽງແຕ່ກ່ຽວກັບການເກັບຮັກສາເທົ່ານັ້ນ; ມັນຍັງກ່ຽວກັບການຄວບຄຸມລະບົບຕ່ອງໂສ້ການສະໜອງຕູ້ຄອນເທນເນີທັງໝົດຂອງທ່ານ. ນັກພັດທະນາທີ່ປະຕິບັດຕໍ່ registry ເປັນຂອບເຂດຄວາມປອດໄພຈະຢຸດຜູ້ໂຈມຕີກ່ອນທີ່ພວກເຂົາຈະຮອດເວລາເຮັດວຽກ.
