ຊຸດ CA ຂອງ Cargo ສຳລັບພຣັອກຊີ ແລະເຊີບເວີແພັກເກດ
ໃຊ້ cainfo ແລະ proxy-cainfo ຂອງ Cargo ກັບການເຊື່ອມຕໍ່ TLS ທີ່ຖືກຕ້ອງ ຢ່າຖືວ່າທຸກຂໍ້ຜິດພາດໃບຢັ້ງຢືນພຣັອກຊີເປັນບັນຫາຄວາມໄວ້ວາງໃຈອັນດຽວ.
ສຳລັບພຣັອກຊີ HTTPS ແລະແຫຼ່ງແພັກເກດ HTTPS, Cargo ສາມາດກວດສອບ ສອງການເຊື່ອມຕໍ່ TLS ດ້ວຍຊຸດ CA ຕ່າງກັນ:
[http]
proxy = "https://proxy.example:8443"
proxy-cainfo = "/path/to/proxy-ca.pem"
cainfo = "/path/to/origin-ca.pem"ປ່ຽນ endpoint ແລະ path ເປັນຄ່າທີ່ອະນຸມັດ. ພຣັອກຊີນີ້ມີ TLS listener ໂດຍຕັ້ງໃຈ; ພຣັອກຊີ HTTP ທົ່ວໄປບໍ່ໄດ້ກາຍເປັນ HTTPS ເພາະແຫຼ່ງແພັກເກດໃຊ້ HTTPS.
| ຂັ້ນຕອນທີ່ຜິດພາດ | ການຕັ້ງຄ່າຄວາມໄວ້ວາງໃຈທີ່ຕ້ອງກວດ |
|---|---|
| TLS ຂອງພຣັອກຊີ ກ່ອນມີ tunnel ໄປປາຍທາງ | http.proxy-cainfo ເຊິ່ງໃຊ້ http.cainfo ຖ້າບໍ່ໄດ້ກຳນົດແຍກຕ່າງຫາກ. |
| ໃບຢັ້ງຢືນປາຍທາງຫຼັງຈາກສ້າງ tunnel | http.cainfo ສຳລັບເສັ້ນທາງຄວາມໄວ້ວາງໃຈຂອງປາຍທາງ. |
ຕົວປ່ຽນທີ່ກົງກັນແມ່ນ CARGO_HTTP_PROXY_CAINFO ແລະ CARGO_HTTP_CAINFO. ໃຊ້ໜ່ວຍອອກໃບຢັ້ງຢືນທີ່ເໝາະສົມແລະອະນຸມັດ; ການຄັດລອກໃບຢັ້ງຢືນແບບສຸ່ມໃສ່ສອງໄຟລ໌ບໍ່ໄດ້ລະບຸວ່າການເຊື່ອມຕໍ່ໃດຜິດ.
ພຣັອກຊີ HTTP ທີ່ບໍ່ເຂົ້າລະຫັດ ແລະຂົນສົ່ງ CONNECT ບໍ່ມີໃບຢັ້ງຢືນ TLS ຂອງ proxy listener ໃຫ້ກວດ. ຂໍ້ຜິດພາດປາຍທາງໃນກໍລະນີນັ້ນບໍ່ໄດ້ແກ້ດ້ວຍໄຟລ໌ CA ພຣັອກຊີທີ່ຄິດຂຶ້ນເອງ. ກວດດ້ວຍວ່າ path ທີ່ຕັ້ງໄວ້ມີໃນ container ຫຼື CI job ຕົວຈິງ ແລະຄຳນຶງເຖິງພຶດຕິກຳຂອງລະບົບປະຕິບັດການ ແລະ TLS backend ເມື່ອປຽບທຽບສະພາບແວດລ້ອມ.
ເປີດການກວດສອບໄວ້. ມັນໃຫ້ການກວດຕົວຕົນທີ່ຈຳເປັນເພື່ອແຍກບໍລິການທີ່ຕ້ອງການອອກຈາກການໂອນທີ່ພຽງແຕ່ດຳເນີນຕໍ່.