การจัดเก็บและส่งต่อข้อมูลรับรองพร็อกซีใน CI/CD โดยไม่รั่วไหล: คู่มือทีละขั้นตอน

ข้อมูลรับรองพร็อกซีหลุดไปในล็อกการ build สาธารณะบ่อยกว่าที่คุณคิด แค่คำสั่ง curl -v ที่ไม่ระวัง ตัวแปรหนึ่งที่แสดงเป็นข้อความธรรมดา หรือรหัสผ่านหนึ่งตัวที่อยู่ใน URL ก็จะทำให้ชื่อผู้ใช้และรหัสผ่านของคุณปรากฏอยู่ในประวัติของไปป์ไลน์ ซึ่งทุกคนในทีมเข้าถึงได้ ในคู่มือนี้ เราจะมาดูวิธีป้องกันไม่ให้สิ่งนี้เกิดขึ้น

บทนำ: ข้อมูลรับรองพร็อกซีรั่วไหลไปในล็อกและประวัติได้อย่างไร

ลองนึกภาพสถานการณ์ทั่วไป คุณกำลังตั้งค่า build ที่ต้องเข้าถึงทรัพยากรภายนอกผ่านพร็อกซี Proxeon เพื่อตรวจสอบการเชื่อมต่ออย่างรวดเร็ว คุณเขียนคำสั่งโดยใส่รหัสผ่านลงใน URL โดยตรง: http://user:pass@host:port Build ผ่านไป คุณดีใจ แต่หนึ่งสัปดาห์ต่อมา คุณพบว่ารหัสผ่านปรากฏอยู่ในล็อกของการรันทุกครั้ง ในประวัติ shell ของ runner และแม้แต่ในเอาต์พุตดีบักของไคลเอนต์

นี่ไม่ใช่เรื่องแปลก แต่เป็นเรื่องปกติ ข้อมูลรับรองพร็อกซีมีคุณสมบัติที่ไม่พึงประสงค์: จำเป็นต้องใช้ในการเรียกเครือข่ายเกือบทุกครั้ง ดังนั้นจึงรั่วไหลไปในหลายสิบแห่งพร้อมกันได้ง่าย

สิ่งที่คุณจะได้เมื่อจบ

หลังจากปฏิบัติตามคู่มือนี้ คุณจะสามารถตั้งค่า CI/CD ของคุณได้โดยที่ข้อมูลรับรองพร็อกซีจะไม่ปรากฏในล็อกใด ๆ ในประวัติคำสั่ง หรือในที่เก็บข้อมูล คุณจะได้เรียนรู้วิธีใช้ความลับของระบบยอดนิยม ปิดโหมดดีบักที่เป็นอันตราย เปลี่ยนรหัสผ่านอย่างปลอดภัยโดยไม่ต้องหยุด build และตรวจสอบทั้งหมดด้วยสคริปต์สำเร็จรูป

คู่มือนี้เหมาะสำหรับใคร

เนื้อหาออกแบบมาสำหรับวิศวกรระดับกลาง: DevOps นักพัฒนาหลังบ้าน และนักอัตโนมัติ QA หากคุณสามารถรันไปป์ไลน์และรู้จักตัวแปรสภาพแวดล้อมได้ คุณจะรู้สึกสบายใจ ผู้อ่านขั้นสูงจะพบส่วนเกี่ยวกับการหมุนเวียนและการตรวจสอบ

สิ่งที่ควรรู้ล่วงหน้า

เราจะไม่อธิบายการตั้งค่าพื้นฐานของตัวแปร http_proxy และ no_proxy ที่นี่ — มีเนื้อหาแยกต่างหากสำหรับเรื่องนี้ สันนิษฐานว่าการเชื่อมต่อพร็อกซีของคุณทำงานอยู่แล้ว และงานตอนนี้คือทำให้การจัดเก็บข้อมูลรับรองปลอดภัย

ใช้เวลาเท่าไร

การอ่านและทำความเข้าใจจะใช้เวลาประมาณ 40 นาที การนำไปใช้ในไปป์ไลน์เดียวจะใช้เวลา 30 นาทีถึงหนึ่งชั่วโมงครึ่ง ขึ้นอยู่กับระบบ CI คุณสามารถเพิ่มการหมุนเวียนและการตรวจสอบการรั่วไหลได้ในภายหลัง โดยใช้เวลาประมาณ 15–20 นาที

การเตรียมการเบื้องต้น: สิ่งที่จำเป็น

ก่อนเริ่มต้น ให้รวบรวมทุกสิ่งที่จำเป็นไว้ก่อน วิธีนี้จะช่วยประหยัดเวลาและป้องกันการถูกขัดจังหวะระหว่างทำงาน

เครื่องมือและการเข้าถึง

• การเข้าถึงโปรเจกต์ CI/CD ของคุณพร้อมสิทธิ์ในการแก้ไขการตั้งค่าและความลับ
• การสมัครสมาชิกพร็อกซี Proxeon ที่ใช้งานได้ พร้อมชื่อผู้ใช้ รหัสผ่าน โฮสต์ และพอร์ต
• เครื่องท้องถิ่นที่ติดตั้ง curl, git รวมถึง Python 3 และ Node.js หากคุณวางแผนจะใช้ตัวอย่างเหล่านี้
• โปรแกรมแก้ไขข้อความสำหรับแก้ไขไฟล์คอนฟิกของไปป์ไลน์

ข้อกำหนดของระบบ

ไม่มีข้อกำหนดพิเศษ ทุกอย่างทำงานบน Linux, macOS และ Windows โดยทั่วไปแล้ว runner ของ CI จะใช้ Linux ดังนั้นตัวอย่างส่วนใหญ่จึงใช้ไวยากรณ์ bash สำหรับ runner บน Windows เราจะกล่าวถึงความแตกต่างแยกต่างหาก

สิ่งที่ต้องเตรียมล่วงหน้า

จดข้อมูลรับรองพร็อกซีปัจจุบันของคุณลงในตัวจัดการรหัสผ่านที่ปลอดภัย ข้อมูลเหล่านี้จำเป็นสำหรับการตั้งค่าความลับ ห้ามเก็บไว้ในไฟล์ข้อความธรรมดาบนเดสก์ท็อป

เคล็ดลับ: สร้างบัญชีพร็อกซีแยกต่างหากสำหรับ CI หากแพ็กเกจ Proxeon ของคุณอนุญาต วิธีนี้ หากข้อมูลรับรอง build ถูกบุกรุก จะไม่กระทบต่อข้อมูลรับรองส่วนตัวของคุณและในทางกลับกัน

สำรองข้อมูลคอนฟิก

ก่อนแก้ไขไปป์ไลน์ ให้สำเนาไฟล์คอนฟิกปัจจุบันไว้ เพียงคัดลอก .gitlab-ci.yml ไฟล์ workflow หรือ Jenkinsfile ไปไว้ในโฟลเดอร์แยกต่างหากนอกที่เก็บข้อมูล

⚠️ ข้อควรระวัง: ห้ามสำรองข้อมูลโดยการ commit ลงในที่เก็บข้อมูลเดียวกันโดยมีรหัสผ่านอยู่ภายใน แม้จะอยู่ใน branch ชั่วคราว ข้อมูลรับรองจะอยู่ในประวัติ git ตลอดไป

แนวคิดพื้นฐาน: คำศัพท์ง่าย ๆ

มาทำความเข้าใจคำสำคัญ ๆ เพื่อไม่ให้สับสนในภายหลัง

ข้อมูลรับรองพร็อกซี

นี่คือชื่อผู้ใช้และรหัสผ่านที่ไคลเอนต์ของคุณใช้ยืนยันสิทธิ์ในการใช้พร็อกซี Proxeon บางครั้งแทนที่จะใช้ชื่อผู้ใช้และรหัสผ่าน อาจใช้การผูกกับ IP แต่ที่นี่เราจะพูดถึงคู่ชื่อผู้ใช้-รหัสผ่าน

ความลับใน CI

Secret คือพื้นที่เก็บข้อมูลพิเศษภายในระบบ CI ที่คุณใส่ค่าที่ละเอียดอ่อน ระบบจะเข้ารหัสและแทนที่ลงใน build เป็นตัวแปรสภาพแวดล้อม ในขณะเดียวกันก็ซ่อนไว้ในล็อกโดยอัตโนมัติ

การมาสก์

Masking คือเมื่อ CI แทนที่ค่าลับในเอาต์พุตด้วยเครื่องหมายดอกจัน หากพิมพ์รหัสผ่านโดยไม่ได้ตั้งใจ คุณจะเห็นสิ่งที่คล้าย [MASKED] แทน ฟีเจอร์นี้ไม่ได้สมบูรณ์แบบเสมอไป ดังนั้นเราจะรวมการป้องกันหลายชั้นเข้าด้วยกัน

ส่วนหัว Proxy-Authorization

เมื่อไคลเอนต์ตรวจสอบสิทธิ์บนพร็อกซี มันจะส่งส่วนหัว HTTP Proxy-Authorization พร้อมข้อมูลรับรองที่เข้ารหัส ในโหมดดีบักโดยละเอียด ไคลเอนต์จำนวนมากจะพิมพ์ส่วนหัวนี้ทั้งหมด การถอดรหัสทำได้ง่ายมาก ดังนั้นเอาต์พุตดังกล่าวจึงถือเป็นการรั่วไหล

ขอบเขตการมองเห็น

ขอบเขต กำหนดว่า build ใดบ้างที่สามารถเข้าถึงความลับได้ ความลับที่จำกัดอย่างถูกต้องจะมองเห็นได้เฉพาะ branch ที่มีการป้องกัน และไม่ตกไปอยู่ใน fork หรือ pull request จากภายนอก

เคล็ดลับ: จำหลักการสำคัญ: ความลับควรอยู่ในหน่วยความจำของกระบวนการเท่าที่จำเป็นเท่านั้น และไม่ควรทิ้งร่องรอยไว้บนดิสก์หรือในเอาต์พุตที่ใด

ขั้นตอนที่ 1: เข้าใจกับดักหลัก — รหัสผ่านใน URL

เป้าหมายของขั้นตอน: เรียนรู้ที่จะจดจำแหล่งที่มาของการรั่วไหลที่พบบ่อยที่สุด และเลิกใช้มันตลอดไป

ข้อผิดพลาดที่พบบ่อยที่สุดคือการใส่ข้อมูลรับรองลงในที่อยู่พร็อกซีโดยตรง: http://user:pass@host:port สะดวก ดังนั้นมือใหม่เกือบทุกคนทำเช่นนี้ ปัญหาคือ URL ดังกล่าวปรากฏขึ้นในที่ที่ไม่คาดคิด

รหัสผ่านจาก URL ปรากฏที่ใดบ้าง

1. รายการกระบวนการ คำสั่ง ps บน runner จะแสดงบรรทัดคำสั่งทั้งหมด รวมถึงรหัสผ่าน กระบวนการใด ๆ บนเครื่องเดียวกันสามารถอ่านได้
2. ล็อกของพร็อกซีเอง ล็อกเซิร์ฟเวอร์บางตัวบันทึกสตริงการเชื่อมต่อ หาก URL มีรหัสผ่าน รหัสผ่านนั้นจะถูกบันทึกในล็อก
3. ประวัติคำสั่งเชลล์ ไฟล์ .bash_history เก็บทุกอย่างที่คุณพิมพ์ รวมถึงรหัสผ่านใน URL
4. เอาต์พุตดีบักของไคลเอนต์ เมื่อรันด้วยโหมดรายละเอียด ไคลเอนต์จะพิมพ์ที่อยู่ปลายทางพร้อมกับข้อมูลรับรอง
5. ล็อก CI หากตัวแปรที่มี URL ไม่ถูกทำเครื่องหมายเป็นความลับ ตัวแปรนั้นจะถูกพิมพ์เป็นข้อความธรรมดาในขั้นตอน echo หรือเมื่อเกิดข้อผิดพลาด

ตรวจสอบตอนนี้เลย รันคำสั่งที่ไม่เป็นอันตรายบนเครื่องใดก็ได้แล้วดูรายการกระบวนการ

curl -x http://myuser:mypass@proxy.proxeon.net:8080 https://example.com & ps aux | grep curl

คุณจะเห็นรหัสผ่านของคุณเป็นข้อความธรรมดาในเอาต์พุต ps นี่คือการรั่วไหลที่เราจะกำจัด

⚠️ ข้อควรระวัง: แม้ว่า build จะเป็นแบบส่วนตัว กระบวนการอื่น งานอื่นบน runner ที่ใช้ร่วมกัน หรือเครื่องมือตรวจสอบอาจเข้าถึงรายการกระบวนการของ runner ได้ ถือว่ารหัสผ่านใน URL เป็นข้อมูลสาธารณะ

ผลลัพธ์ที่คาดหวัง: คุณเข้าใจห้าจุดที่รั่วไหล และจะไม่เขียนรหัสผ่านในที่อยู่พร็อกซีอีกต่อไป

✅ การตรวจสอบ: รันคำสั่งทดสอบด้านบนและตรวจสอบว่าคุณเห็นรหัสผ่านในเอาต์พุต ps หากเห็น แสดงว่าคุณจำลองปัญหาได้ถูกต้องและพร้อมที่จะแก้ไข

ขั้นตอนที่ 2: วิธีที่ถูกต้อง — ตัวแปรสภาพแวดล้อมและไฟล์ข้อมูลรับรอง

เป้าหมายของขั้นตอน: ย้ายข้อมูลรับรองจาก URL ไปยังพื้นที่เก็บข้อมูลที่ปลอดภัย — ตัวแปรสภาพแวดล้อมและไฟล์เฉพาะ

แนวคิดง่าย ๆ เก็บชื่อผู้ใช้และรหัสผ่านแยกจากที่อยู่ ไคลเอนต์อ่านจากสภาพแวดล้อมหรือไฟล์ที่มีสิทธิ์จำกัด ไม่ใช่จากบรรทัดคำสั่ง เพื่อไม่ให้ตกไปในรายการกระบวนการและประวัติ

ตัวเลือก A: ตัวแปรสภาพแวดล้อม

ไคลเอนต์หลายตัวสามารถอ่านข้อมูลรับรองพร็อกซีจากสภาพแวดล้อมได้ มาดูตัวอย่าง

curl ผ่านตัวแปรสภาพแวดล้อม

ตั้งค่าที่อยู่พร็อกซีโดยไม่มีข้อมูลรับรอง และส่งชื่อผู้ใช้และรหัสผ่านด้วยแฟล็กแยกต่างหาก โดยนำค่ามาจากตัวแปร

1. ส่งออกตัวแปรที่มีข้อมูลรับรองไปยังสภาพแวดล้อม (ใน CI ความลับจะทำสิ่งนี้ ในเครื่อง — แหล่งที่ปลอดภัย)
2. ส่งค่าผ่านแฟล็ก -U แทนที่จะเป็นใน URL

export PROXY_CREDS="$PROXEON_USER:$PROXEON_PASS"; curl -x http://proxy.proxeon.net:8080 -U "$PROXY_CREDS" https://example.com

แม้แต่แฟล็ก -U พร้อมตัวแปรก็ยังดีกว่ารหัสผ่านใน URL แต่ก็ยังมองเห็นได้ใน ps ดังนั้นจึงควรใช้ไฟล์ข้อมูลรับรองตามที่กล่าวถึงด้านล่าง

Python requests

ใน Python อ่านข้อมูลรับรองจากสภาพแวดล้อมผ่าน os.environ และสร้างพจนานุกรม proxies ในหน่วยความจำ อย่าพิมพ์สิ่งใด

import os, requests; user=os.environ['PROXEON_USER']; pwd=os.environ['PROXEON_PASS']; proxy=f'http://{user}:{pwd}@proxy.proxeon.net:8080'; r=requests.get('https://example.com', proxies={'http':proxy,'https':proxy}); print(r.status_code)

ที่นี่รหัสผ่านยังคงอยู่ในตัวแปรภายในกระบวนการ Python และไม่ตกไปในบรรทัดคำสั่ง สิ่งสำคัญคืออย่าบันทึกตัวแปร proxy ทั้งหมด

Node.js

ใน Node ให้นำข้อมูลรับรองจาก process.env และสร้างพร็อกซีเอเจนต์ในโค้ด

const user=process.env.PROXEON_USER; const pass=process.env.PROXEON_PASS; const proxyUrl=`http://${user}:${pass}@proxy.proxeon.net:8080`; const {HttpsProxyAgent}=require('https-proxy-agent'); const agent=new HttpsProxyAgent(proxyUrl); fetch('https://example.com',{agent}).then(r=>console.log(r.status));

เคล็ดลับ: ในภาษาใดก็ตาม ให้บันทึกเฉพาะสถานะการตอบสนองและโฮสต์ปลายทาง (หากจำเป็น) ลงในล็อก ห้ามพิมพ์ออบเจกต์ที่มีการตั้งค่าพร็อกซีทั้งหมด — มีรหัสผ่านอยู่ข้างใน

ตัวเลือก B: ไฟล์ .netrc

ไฟล์ .netrc เป็นวิธีคลาสสิกในการเก็บข้อมูลรับรองแยกจากคำสั่ง curl อ่านไฟล์นี้ได้โดยอัตโนมัติ

1. สร้างไฟล์ .netrc ในโฮมไดเรกทอรีของ runner ทันที จากความลับของ CI
2. เขียนบรรทัดที่มีเครื่อง ชื่อผู้ใช้ และรหัสผ่าน
3. ตั้งค่าสิทธิ์การเข้าถึงเป็น 600 เพื่อให้เฉพาะเจ้าของอ่านไฟล์ได้
4. รัน curl ด้วยแฟล็กที่ใช้ netrc

printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

ตอนนี้รหัสผ่านไม่ปรากฏในบรรทัดคำสั่งหรือรายการกระบวนการ รหัสผ่านอยู่ในไฟล์ที่มีสิทธิ์ 600 ซึ่งคุณจะลบเมื่อสิ้นสุด build

⚠️ ข้อควรระวัง: สิทธิ์ 600 เป็นข้อบังคับ หากไม่มี curl อาจปฏิเสธที่จะอ่านไฟล์ และไฟล์เองก็จะพร้อมใช้งานโดยผู้ใช้รายอื่นบนเครื่อง

ตัวเลือก C: คอนฟิก curl

curl สามารถอ่านแฟล็กจากไฟล์คอนฟิกได้ ใส่พร็อกซีและข้อมูลรับรองลงไป ตั้งค่าสิทธิ์เป็น 600

printf 'proxy = http://proxy.proxeon.net:8080\nproxy-user = "%s:%s"\n' "$PROXEON_USER" "$PROXEON_PASS" > ~/.curlrc; chmod 600 ~/.curlrc; curl https://example.com

เมื่อมี .curlrc ที่มีสิทธิ์ 600 ข้อมูลรับรองจะไม่ปรากฏในกระบวนการและไม่ถูกเขียนลงในประวัติ

ตัวเลือก D: คอนฟิกไคลเอนต์ของแอปพลิเคชัน

หากคุณมีแอปพลิเคชันของตัวเองที่อ่านคอนฟิก ให้เก็บข้อมูลรับรองพร็อกซีในไฟล์คอนฟิกนอกที่เก็บข้อมูล เก็บเฉพาะเทมเพลตที่มีตัวยึดตำแหน่งในที่เก็บข้อมูล และแทนที่ค่าจริงบน runner จากความลับ

ผลลัพธ์ที่คาดหวัง: ในตัวอย่างทั้งหมด รหัสผ่านไม่ปรากฏในบรรทัดคำสั่งหรือรายการกระบวนการ รหัสผ่านอยู่ในตัวแปรภายในกระบวนการหรือในไฟล์ที่มีสิทธิ์ 600

✅ การตรวจสอบ: รันตัวอย่างใดก็ได้และรัน ps aux | grep curl พร้อมกัน ต้องไม่มีรหัสผ่านในเอาต์พุต หากใช้ netrc ให้ตรวจสอบสิทธิ์ด้วยคำสั่ง ls -l ~/.netrc — ควรเป็น -rw-------

ขั้นตอนที่ 3: ความลับใน CI ยอดนิยม — GitHub Actions, GitLab CI, Jenkins

เป้าหมายของขั้นตอน: วางข้อมูลรับรองพร็อกซีในพื้นที่เก็บข้อมูลที่ปลอดภัยของระบบ CI และแทนที่โดยไม่รั่วไหล

GitHub Actions

ใน GitHub ความลับจะถูกเก็บไว้ที่ระดับที่เก็บข้อมูลหรือองค์กร

1. เปิดที่เก็บข้อมูลและไปที่ส่วนการตั้งค่า Settings
2. ทางซ้ายมือ ค้นหารายการ Secrets and variables จากนั้น Actions
3. คลิกปุ่ม New repository secret
4. ป้อนชื่อ เช่น PROXEON_USER และค่า — ชื่อผู้ใช้ของคุณ บันทึก
5. ทำซ้ำสำหรับ PROXEON_PASS ด้วยรหัสผ่าน

ใน workflow ให้เข้าถึงความลับผ่านคอนเทกซ์ secrets และส่งต่อไปยังขั้นตอนเป็นตัวแปรสภาพแวดล้อม

steps: - name: request env: PROXEON_USER: ${{ secrets.PROXEON_USER }} PROXEON_PASS: ${{ secrets.PROXEON_PASS }} run: printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

GitHub จะมาสก์ค่าความลับในล็อกโดยอัตโนมัติ หากพิมพ์รหัสผ่านโดยไม่ได้ตั้งใจ คุณจะเห็นเครื่องหมายดอกจันสามตัว

⚠️ ข้อควรระวัง: โดยค่าเริ่มต้น ความลับจะไม่พร้อมใช้งานใน workflow ที่รันจาก fork ผ่าน pull_request อย่าเปลี่ยนพฤติกรรมนี้เป็น pull_request_target เว้นแต่จำเป็นจริง ๆ — ผู้มีส่วนร่วมภายนอกอาจได้รับข้อมูลรับรองของคุณ

GitLab CI

ใน GitLab ความลับเรียกว่าตัวแปร CI/CD และตั้งค่าในโปรเจกต์

1. เปิดโปรเจกต์ ไปที่ Settings จากนั้น CI/CD
2. ขยายส่วน Variables และคลิก Add variable
3. ป้อนคีย์ PROXEON_USER และค่า
4. ทำเครื่องหมายที่ช่อง Masked เพื่อซ่อนค่าในล็อก
5. ทำเครื่องหมายที่ช่อง Protected เพื่อให้ตัวแปรพร้อมใช้งานเฉพาะ branch และแท็กที่ได้รับการป้องกัน
6. ทำซ้ำสำหรับ PROXEON_PASS

ใน .gitlab-ci.yml ตัวแปรจะพร้อมใช้งานโดยอัตโนมัติเป็นสภาพแวดล้อม

request: script: - printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc - chmod 600 ~/.netrc - curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

เคล็ดลับ: แฟล็ก Masked ใน GitLab ใช้งานได้กับค่าที่ตรงตามกฎ: ความยาวขั้นต่ำ ไม่มีตัวแบ่งบรรทัด ชุดอักขระที่เข้ากันได้กับ base64 หากรหัสผ่านไม่ถูกมาสก์ GitLab จะแสดงคำเตือนเมื่อบันทึก ในกรณีนี้ ให้เปลี่ยนรหัสผ่านให้ตรงตามข้อกำหนด

Jenkins

ใน Jenkins ข้อมูลรับรองจะถูกเก็บไว้ในส่วน Credentials และถูกแทนที่ผ่านปลั๊กอิน Credentials Binding

1. เปิด Manage Jenkins จากนั้น Credentials
2. เลือกขอบเขตที่เหมาะสม เช่น System และ Global credentials
3. คลิก Add Credentials
4. เลือกประเภท Username with password
5. ป้อนชื่อผู้ใช้และรหัสผ่านพร็อกซี ตั้งค่า ID ที่ชัดเจน เช่น proxeon-creds

ใน Jenkinsfile ให้ครอบการใช้งานด้วยบล็อก withCredentials Jenkins จะมาสก์ค่าในคอนโซล

withCredentials([usernamePassword(credentialsId: 'proxeon-creds', usernameVariable: 'PROXEON_USER', passwordVariable: 'PROXEON_PASS')]) { sh 'printf "machine proxy.proxeon.net login %s password %s" "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com' }

⚠️ ข้อควรระวัง: Jenkins มาสก์เฉพาะค่าที่กำหนดผ่าน Credentials Binding เท่านั้น หากคุณสร้างรหัสผ่านเป็นสตริงใน Groovy แล้วพิมพ์ออกมา การมาสก์จะไม่ทำงาน ทำงานกับข้อมูลรับรองภายในบล็อก withCredentials และในขั้นตอน sh เท่านั้น

ผลลัพธ์ที่คาดหวัง: ข้อมูลรับรองอยู่ในพื้นที่เก็บข้อมูลที่ปลอดภัยของระบบ CI ของคุณ ถูกแทนที่ใน build เป็นสภาพแวดล้อม และถูกมาสก์ในล็อก

✅ การตรวจสอบ: รัน build และเปิดล็อก ตรวจสอบว่าเห็นเครื่องหมายดอกจันหรือเครื่องหมายการมาสก์แทนรหัสผ่าน ลองพิมพ์ตัวแปรผ่าน echo โดยตั้งใจ — ระบบควรซ่อนมัน

ขั้นตอนที่ 4: ล็อก — ปิดโหมดที่พิมพ์ Proxy-Authorization

เป้าหมายของขั้นตอน: ลบเอาต์พุตโดยละเอียดที่เปิดเผยส่วนหัวการอนุญาต และคงระดับการบันทึกที่ปลอดภัย

การมาสก์ CI ไม่ใช่ยาครอบจักรวาล หากไคลเอนต์พิมพ์ส่วนหัว Proxy-Authorization ในรูปแบบ base64 และระบบไม่รู้จักรหัสผ่านต้นฉบับแบบคำต่อคำ การมาสก์อาจไม่ทำงาน ดังนั้นเราจะปิดโหมดอันตรายที่ต้นทาง

curl

แฟล็ก -v และโดยเฉพาะ --trace พิมพ์ส่วนหัว รวมถึงการอนุญาตพร็อกซี ใน CI ให้ใช้โหมดเงียบ

1. ลบ -v, --verbose, --trace และ --trace-ascii ออกจากคำสั่ง build
2. สำหรับการควบคุมข้อผิดพลาด ให้ใช้ -sS: เงียบแต่แสดงข้อผิดพลาด
3. หากต้องการดีบัก ให้ใช้ --trace เฉพาะในเครื่อง และไม่ใช้ใน CI

curl -sS --netrc -x http://proxy.proxeon.net:8080 https://example.com -o /dev/null -w '%{http_code}'

วิธีนี้คุณจะได้รับเฉพาะรหัสตอบสนองโดยไม่มีส่วนหัวใด ๆ ในเอาต์พุต

Python requests

ไลบรารี requests ไม่พิมพ์ข้อมูลรับรองเอง แต่การเปิด log urllib3 ที่ระดับ DEBUG จะพิมพ์ส่วนหัวของคำขอ เก็บระดับ log ไว้ที่ WARNING หรือ INFO

import logging; logging.getLogger('urllib3').setLevel(logging.WARNING)

เคล็ดลับ: หากจำเป็นต้องใช้ DEBUG สำหรับการวินิจฉัย ให้เพิ่มตัวกรอง log ที่ตัดส่วนหัว Proxy-Authorization ออกจากข้อความ แต่การวินิจฉัยในเครื่องนั้นง่ายกว่า และใน CI ใช้ WARNING

Node.js

ใน Node หลีกเลี่ยงการตั้งตัวแปร NODE_DEBUG=http ใน CI — มันพิมพ์ส่วนหัว นอกจากนี้ยังไม่ควรพิมพ์ออบเจกต์ agent และออบเจกต์คำขอทั้งหมด

1. ลบ NODE_DEBUG ออกจากสภาพแวดล้อมของ runner
2. ในตัวจัดการข้อผิดพลาด ให้พิมพ์เฉพาะ error.message ไม่ใช่ออบเจกต์ทั้งหมด
3. อย่าใช้ไลบรารีบันทึกคำขอ HTTP ใน build การผลิต

⚠️ ข้อควรระวัง: สแตกเทรซของข้อยกเว้นที่ไม่มีการจัดการอาจมี URL พร็อกซีพร้อมข้อมูลรับรอง หากคุณสร้าง URL พร้อมรหัสผ่าน นี่เป็นอีกเหตุผลที่ไม่ควรใส่รหัสผ่านใน URL แต่ใช้ netrc หรือฟิลด์แยก

ผลลัพธ์ที่คาดหวัง: ไม่มีเครื่องมือใดใน CI พิมพ์ส่วนหัวการอนุญาตและ URL พร็อกซีทั้งหมด

✅ การตรวจสอบ: รัน build และค้นหาในล็อกสำหรับสตริง Proxy-Authorization, Basic และชื่อผู้ใช้ของคุณ ไม่ควรมีการจับคู่เลย

ขั้นตอนที่ 5: การหมุนเวียนรหัสผ่านพร็อกซีโดยไม่หยุด build

เป้าหมายของขั้นตอน: เรียนรู้วิธีเปลี่ยนรหัสผ่านเพื่อให้ build ไม่ล้มเหลวและรหัสผ่านเก่าไม่ทำงานอีกต่อไป

ควรเปลี่ยนรหัสผ่านพร็อกซีเป็นระยะ ๆ และจำเป็นต้องเปลี่ยนทันทีเมื่อสงสัยว่ามีการรั่วไหล งานคือทำสิ่งนี้โดยไม่มีช่วงเวลาที่ build หยุดทำงาน

กลยุทธ์การทับซ้อน

ตัวเลือกที่ดีที่สุดคือเมื่อทั้งรหัสผ่านเก่าและใหม่ทำงานอยู่ในช่วงเวลาหนึ่ง หากแพ็กเกจ Proxeon ของคุณอนุญาตให้สร้างบัญชีที่สองหรือชุดข้อมูลรับรองเพิ่มเติม ให้ใช้สิ่งนี้

1. สร้างข้อมูลรับรองพร็อกซีใหม่ในบัญชีส่วนตัว Proxeon โดยไม่ลบข้อมูลเก่า
2. เพิ่มค่าใหม่ในความลับ CI ภายใต้ชื่อชั่วคราว เช่น PROXEON_USER_NEW
3. สลับไปป์ไลน์ไปยังชื่อใหม่ใน branch แยกต่างหากและรัน build
4. ตรวจสอบว่า build ผ่านด้วยข้อมูลรับรองใหม่
5. แทนที่ค่าของความลับหลัก PROXEON_USER และ PROXEON_PASS ด้วยค่าใหม่
6. ลบความลับชั่วคราว
7. เพิกถอนข้อมูลรับรองเก่าในบัญชี Proxeon

วิธีนี้ในทุกช่วงเวลาจะมีชุดข้อมูลรับรองที่ใช้งานได้ และ build จะไม่ล้มเหลว

หากการทับซ้อนไม่พร้อมใช้งาน

เมื่อมีเพียงคู่ข้อมูลรับรองเดียว ให้ดำเนินการในช่วงเวลาที่เงียบสงบ

1. เลือกเวลาที่มีกิจกรรม build น้อยที่สุด
2. หยุดการรันไปป์ไลน์ใหม่ชั่วคราวสองสามนาที
3. เปลี่ยนรหัสผ่านในบัญชี Proxeon
4. อัปเดตค่าความลับใน CI ทันที
5. รัน build ตรวจสอบ
6. กลับมาทำงานตามปกติ

เคล็ดลับ: จัดทำขั้นตอนการหมุนเวียนสั้น ๆ และเก็บไว้ใกล้กับคำอธิบายไปป์ไลน์ ในสถานการณ์กดดันหลังการรั่วไหล รายการขั้นตอนพร้อมใช้จะช่วยประหยัดความกังวลและเวลา

⚠️ ข้อควรระวัง: หลังจากเปลี่ยนรหัสผ่าน ต้องลบไฟล์ netrc หรือ curlrc เก่าบน runner หากมีการแคชระหว่าง build มิฉะนั้นไคลเอนต์จะยังคงใช้ข้อมูลรับรองเก่า

ผลลัพธ์ที่คาดหวัง: เปลี่ยนรหัสผ่านแล้ว build ใหม่ใช้ข้อมูลรับรองใหม่ รหัสผ่านเก่าไม่ทำงานอีกต่อไป

✅ การตรวจสอบ: ลองเรียกคำขอด้วยรหัสผ่านเก่า — ควรได้รับข้อผิดพลาดการอนุญาตพร็อกซี ในขณะที่ build ใหม่ผ่านด้วยความสำเร็จ

ขั้นตอนที่ 6: การตรวจสอบการรั่วไหล — สคริปต์ตรวจสอบสำเร็จรูป

เป้าหมายของขั้นตอน: ตรวจสอบให้แน่ใจว่าไม่มีข้อมูลรับรองในอาร์ติแฟกต์ ล็อก และที่เก็บข้อมูล และทำให้การตรวจสอบนี้เป็นอัตโนมัติ

จะค้นหาที่ไหน

• อาร์ติแฟกต์ของ build: ไฟล์ที่สร้าง รายงาน ดัมพ์
• ล็อกของไปป์ไลน์ รวมถึงการรันเก่า
• ประวัติที่เก็บข้อมูล git
• แคชและไฟล์ชั่วคราวของ runner

การค้นหาในอาร์ติแฟกต์และล็อก

ดาวน์โหลดอาร์ติแฟกต์และล็อกไปยังโฟลเดอร์ท้องถิ่น และค้นหาด้วยเครื่องหมายลักษณะเฉพาะ: ชื่อผู้ใช้ ส่วนหนึ่งของรหัสผ่าน คำว่า Basic และส่วนหัวการอนุญาต

grep -RniE 'proxy-authorization|Basic [A-Za-z0-9+/=]{8,}|proxeon.*login|:[^@/]+@proxy' ./artifacts ./logs

สคริปต์ค้นหาส่วนหัวการอนุญาต สตริง base64 หลังคำว่า Basic รูปแบบชื่อผู้ใช้ใน netrc และสัญญาณของรหัสผ่านใน URL ก่อนเครื่องหมาย @ การจับคู่ใด ๆ เป็นเหตุให้ต้องสอบสวน

การค้นหาในประวัติ git

รหัสผ่านอาจตกอยู่ใน commit เก่า ตรวจสอบประวัติทั้งหมด

git log -p -S 'proxy.proxeon.net' --all | grep -nE ':[^@/]+@proxy|password [^ ]+'

⚠️ ข้อควรระวัง: หากพบรหัสผ่านในประวัติ git การลบไฟล์เพียงอย่างเดียวไม่เพียงพอ — รหัสผ่านจะยังคงอยู่ใน commit เก่า จำเป็นต้องเขียนประวัติใหม่ด้วยเครื่องมือพิเศษ และที่สำคัญกว่านั้นคือ เปลี่ยนรหัสผ่านทันที ถือว่ารหัสผ่านดังกล่าวถูกบุกรุก

การทำงานอัตโนมัติในไปป์ไลน์

เพิ่ม job แยกต่างหากที่สแกนอาร์ติแฟกต์ที่สร้างก่อนการเผยแพร่และล้มเหลวเมื่อพบ ตัวป้องกันดังกล่าวจะจับการรั่วไหลก่อนที่จะออกไปภายนอก

leak_check: script: - if grep -RniE 'proxy-authorization|Basic [A-Za-z0-9+/=]{8,}' ./artifacts; then echo 'LEAK DETECTED'; exit 1; fi

เคล็ดลับ: เพิ่มสแกนเนอร์ความลับสำเร็จรูปในขั้นตอน pre-commit ในเครื่อง พวกมันจับข้อมูลรับรองก่อน commit ไม่ให้ตกไปในที่เก็บข้อมูล

ผลลัพธ์ที่คาดหวัง: การตรวจสอบด้วยตนเองและ job อัตโนมัติยืนยันว่าไม่มีข้อมูลรับรองในที่ใด

✅ การตรวจสอบ: รันสคริปต์ตรวจสอบ — ควรสิ้นสุดโดยไม่มีการจับคู่ จากนั้นจงใจใส่สตริงทดสอบที่มีเครื่องหมาย Basic ในอาร์ติแฟกต์และตรวจสอบว่าสคริปต์พบและล้มเหลว

ขั้นตอนที่ 7: รายการตรวจสอบก่อนนำไปป์ไลน์ออกใช้

เป้าหมายของขั้นตอน: ผ่านการตรวจสอบขั้นสุดท้ายก่อนเปิดใช้งานไปป์ไลน์

ทำเครื่องหมายแต่ละรายการในรายการ หากมีข้อใดไม่สำเร็จ อย่านำไปป์ไลน์ออกใช้

1. รหัสผ่านพร็อกซีไม่ได้ถูกเขียนใน URL ในรูปแบบ user:pass@host
2. ชื่อผู้ใช้และรหัสผ่านถูกเก็บไว้ในความลับของ CI เท่านั้น ไม่ใช่ในไฟล์ที่เก็บข้อมูล
3. ความลับถูกทำเครื่องหมายว่าสามารถมาสก์ได้และป้องกันได้
4. ความลับไม่พร้อมใช้งานสำหรับ build จาก fork และ pull request ภายนอก
5. ลบแฟล็กโหมดรายละเอียดและการติดตามออกจากคำสั่งแล้ว
6. ระดับ log ของไลบรารี HTTP ไม่ใช่ DEBUG
7. ตัวแปรดีบักเช่น NODE_DEBUG ไม่มีอยู่ในสภาพแวดล้อมของ runner
8. ไฟล์ netrc และ curlrc ถูกสร้างขึ้นทันทีและมีสิทธิ์ 600
9. ไฟล์ข้อมูลรับรองถูกลบเมื่อสิ้นสุด build หรืออยู่ใน runner ชั่วคราว
10. มี job ตรวจสอบการรั่วไหลในไปป์ไลน์
11. ตรวจสอบประวัติ git แล้วและไม่มีข้อมูลรับรอง
12. มีขั้นตอนการหมุนเวียนรหัสผ่าน

เคล็ดลับ: บันทึกรายการตรวจสอบนี้เป็นเทมเพลตและแนบกับไปป์ไลน์ใหม่ทุกอันที่ใช้พร็อกซี ความสม่ำเสมอช่วยลดจำนวนข้อผิดพลาด

✅ การตรวจสอบ: ทำเครื่องหมายครบทั้งสิบสองข้อ ถึงตอนนี้ไปป์ไลน์พร้อมสำหรับการนำออกใช้แล้ว

การตรวจสอบผลลัพธ์: วิธีแน่ใจว่าทุกอย่างทำงาน

มารวบรวมการตรวจสอบขั้นสุดท้ายเป็นสถานการณ์เดียว

รายการตรวจสอบการทำงาน

• build เข้าถึงผ่านพร็อกซี Proxeon ได้สำเร็จและได้รับการตอบสนองที่ต้องการ
• ไม่มีรหัสผ่าน ชื่อผู้ใช้ สตริง base64 การอนุญาต หรือ URL พร็อกซีทั้งหมดในล็อก build
• ไม่มีรหัสผ่านในรายการกระบวนการของ runner ระหว่างการเรียก
• อาร์ติแฟกต์สะอาด สคริปต์ตรวจสอบไม่พบการจับคู่
• ความลับถูกมาสก์แม้จะ echo โดยตั้งใจ

วิธีทดสอบ

1. รันไปป์ไลน์ทั้งหมดตั้งแต่ต้นจนจบ
2. เปิดล็อกและค้นหาชื่อผู้ใช้ — ไม่ควรมีการจับคู่
3. ดาวน์โหลดอาร์ติแฟกต์และรันสคริปต์ตรวจสอบกับอาร์ติแฟกต์
4. ตรวจสอบ job การตรวจสอบการรั่วไหล — ควรผ่านเป็นสีเขียว

ตัวชี้วัดความสำเร็จ

ความสำเร็จมีลักษณะดังนี้: build เป็นสีเขียว การเรียกผ่านพร็อกซีสำเร็จ และการค้นหาทุกที่ที่เป็นไปได้ไม่พบชิ้นส่วนของข้อมูลรับรอง หากเป็นเช่นนั้น แสดงว่าคุณบรรลุเป้าหมายของคู่มือแล้ว

ข้อผิดพลาดทั่วไปและแนวทางแก้ไข

มาดูปัญหาที่พบบ่อยตามรูปแบบ ปัญหา สาเหตุ วิธีแก้ไข

ปัญหา 1: รหัสผ่านยังคงปรากฏในล็อก

สาเหตุ: ตัวแปรถูกสร้างเป็นตัวแปรปกติ ไม่ใช่ความลับ หรือไม่ถูกทำเครื่องหมายว่าสามารถมาสก์ได้

วิธีแก้ไข: ย้ายค่าไปยังส่วนความลับ เปิดการมาสก์ และตรวจสอบว่าชื่อตัวแปรตรงกันในคอนฟิกและในพื้นที่เก็บข้อมูล

ปัญหา 2: การมาสก์ไม่ทำงานใน GitLab

สาเหตุ: รหัสผ่านมีอักขระหรือตัวแบ่งบรรทัดที่ไม่ได้รับอนุญาตสำหรับการมาสก์

วิธีแก้ไข: เปลี่ยนรหัสผ่านเป็นสตริงที่ประกอบด้วยตัวอักษร ตัวเลข และอักขระที่ยอมรับได้ซึ่งมีความยาวเพียงพอ ตรงตามข้อกำหนดการมาสก์

ปัญหา 3: curl ไม่อ่าน netrc

สาเหตุ: ไฟล์มีสิทธิ์ไม่ถูกต้องหรือไม่อยู่ในโฮมไดเรกทอรี

วิธีแก้ไข: ตั้งค่าสิทธิ์เป็น 600 ด้วยคำสั่ง chmod และตรวจสอบว่าเส้นทางไปยังไฟล์ตรงกับที่คาดหวัง หรือระบุเส้นทางด้วยแฟล็ก netrc-file

ปัญหา 4: รหัสผ่านในสแตกเทรซเมื่อเกิดข้อผิดพลาด

สาเหตุ: URL พร็อกซีถูกสร้างพร้อมข้อมูลรับรอง และไคลเอนต์พิมพ์มันในข้อยกเว้น

วิธีแก้ไข: เปลี่ยนไปใช้ netrc หรือฟิลด์ชื่อผู้ใช้และรหัสผ่านแยกกัน เพื่อให้ URL ไม่มีข้อมูลรับรอง และพิมพ์เฉพาะข้อความข้อผิดพลาด

ปัญหา 5: รหัสผ่านเก่ายังคงถูกใช้หลังการหมุนเวียน

สาเหตุ: ไฟล์ netrc หรือ curlrc ที่ถูกแคชยังคงอยู่บน runner

วิธีแก้ไข: ลบไฟล์ข้อมูลรับรองเมื่อสิ้นสุด build ทุกครั้ง และใช้ runner ชั่วคราวที่ระบบไฟล์ถูกล้างระหว่างการรัน

ปัญหา 6: ความลับรั่วไหลใน fork-pull-request

สาเหตุ: เปิดโหมดที่ให้ PR ภายนอกเข้าถึงความลับ

วิธีแก้ไข: ปิดโหมดดังกล่าว รัน build ด้วยความลับสำหรับ branch ที่เชื่อถือได้เท่านั้น และทำการตรวจสอบ PR ภายนอกโดยไม่ต้องเข้าถึงพร็อกซี

ปัญหา 7: พบรหัสผ่านในประวัติ git

สาเหตุ: เคย commit ข้อมูลรับรองในไฟล์คอนฟิก

วิธีแก้ไข: เปลี่ยนรหัสผ่านทันที จากนั้นเขียนประวัติที่เก็บข้อมูลใหม่ โดยลบข้อมูลที่ละเอียดอ่อนออกจาก commit ทั้งหมด

ความสามารถเพิ่มเติม: การป้องกันขั้นสูง

เมื่อตั้งค่าการป้องกันพื้นฐานแล้ว คุณสามารถเสริมความแข็งแกร่งได้

ตัวจัดการความลับภายนอก

แทนที่จะเก็บข้อมูลรับรองในระบบ CI เอง ให้เชื่อมต่อตัวจัดการความลับภายนอก ไปป์ไลน์จะได้รับข้อมูลรับรองผ่านโทเค็นที่มีอายุสั้นเฉพาะช่วง build เท่านั้น วิธีนี้ความลับจะไม่อยู่ในการตั้งค่าโปรเจกต์อย่างถาวร

โทเค็นอายุสั้นแทนรหัสผ่าน

หากโครงสร้างพื้นฐาน Proxeon และรูปแบบการเข้าถึงของคุณรองรับ ให้เลือกใช้โทเค็นชั่วคราวที่มีอายุจำกัด แม้รั่วไหล โทเค็นดังกล่าวจะไร้ประโยชน์อย่างรวดเร็ว

การแยกข้อมูลรับรองตามสภาพแวดล้อม

ใช้ข้อมูลรับรองที่แตกต่างกันสำหรับ build ทดสอบและการผลิต การบุกรุกข้อมูลรับรองทดสอบจะไม่กระทบกระบวนการผลิต

เคล็ดลับ: ตั้งค่าการแจ้งเตือนเกี่ยวกับกิจกรรมที่ผิดปกติบนบัญชีพร็อกซี การเพิ่มขึ้นอย่างกะทันหันของคำขอหรือการเชื่อมต่อจากแหล่งที่ไม่คาดคิด — สัญญาณของการรั่วไหลที่อาจเกิดขึ้น ต้องหมุนเวียนทันที

การหมุนเวียนอัตโนมัติ

ทีมขั้นสูงจะทำให้การหมุนเวียนเป็นอัตโนมัติตามกำหนดเวลา: สคริปต์สร้างข้อมูลรับรองใหม่ อัปเดตความลับ และเพิกถอนข้อมูลเก่าโดยไม่ต้องใช้คน เริ่มต้นด้วยขั้นตอนด้วยตนเอง และเพิ่มระบบอัตโนมัติเมื่อกระบวนการทำงานได้ดี

FAQ: คำถามที่พบบ่อย

ฉันสามารถไว้วางใจการมาสก์ของ CI และไม่ต้องกังวลได้หรือไม่?

ไม่ได้ การมาสก์จับเฉพาะการจับคู่ที่ตรงกันของค่าที่รู้จัก ส่วนหัวในรูปแบบ base64 หรือเอาต์พุตบางส่วนอาจถูกข้ามไป รวมการมาสก์กับการไม่ใช้รหัสผ่านใน URL และการปิดล็อกโดยละเอียด

อะไรปลอดภัยกว่า: ตัวแปรสภาพแวดล้อมหรือไฟล์ netrc?

ไฟล์ netrc ที่มีสิทธิ์ 600 ดีกว่าสำหรับ curl เพราะค่าไม่ตกไปในรายการกระบวนการด้วยซ้ำ สำหรับโค้ด Python และ Node ตัวแปรสภาพแวดล้อมที่อ่านภายในกระบวนการจะสะดวกกว่า ทั้งสองตัวเลือกปลอดภัยหากจัดการอย่างระมัดระวัง

ฉันต้องลบไฟล์ข้อมูลรับรองหลัง build หรือไม่?

ใช่ หาก runner ถูกใช้ซ้ำ บน runner ชั่วคราวที่เครื่องถูกทำลายหลัง build จะสำคัญน้อยกว่า แต่การลบเมื่อสิ้นสุดเป็นนิสัยที่ดีเสมอ

จะทำอย่างไรหารหัสผ่านพร็อกซีมีอักขระพิเศษ?

ใน netrc และฟิลด์แยก อักขระพิเศษมักไม่เป็นปัญหา ปัญหาเกิดขึ้นเมื่อใส่ใน URL ซึ่งอักขระเช่น @ และ : จะทำให้การแยกวิเคราะห์พัง นี่เป็นอีกเหตุผลที่ไม่ควรใส่รหัสผ่านใน URL

requests พิมพ์ข้อมูลรับรองเองหรือไม่?

โดยค่าเริ่มต้นไม่ใช่ การรั่วไหลเกิดขึ้นเมื่อเปิด log DEBUG ของ urllib3 หรือเมื่อพิมพ์ออบเจกต์การตั้งค่าพร็อกซี เก็บ log ที่ WARNING และอย่าพิมพ์การตั้งค่าทั้งหมด

รหัสผ่านปรากฏในรายการกระบวนการเมื่อใช้แฟล็ก proxy-user หรือไม่?

ใช่ แฟล็กในบรรทัดคำสั่งมองเห็นได้ใน ps ดังนั้นสำหรับ curl ควรใช้ netrc หรือ curlrc ซึ่งไม่ส่งข้อมูลรับรองเป็นอาร์กิวเมนต์

ควรเปลี่ยนรหัสผ่านพร็อกซีบ่อยแค่ไหน?

การหมุนเวียนตามแผนควรทำเป็นประจำ เช่น ทุกไตรมาส และจำเป็นต้องทำทันทีเมื่อสงสัยว่ามีการรั่วไหล ขั้นตอนการหมุนเวียนจากขั้นตอนที่ 5 จะช่วยให้ทำได้อย่างรวดเร็ว

ฉันสามารถเก็บข้อมูลรับรองในไฟล์เข้ารหัสในที่เก็บข้อมูลได้หรือไม่?

ในทางเทคนิคได้ แต่ทำให้กระบวนการซับซ้อนและเสี่ยงต่อการรั่วไหลของคีย์เข้ารหัส ความลับ CI และตัวจัดการความลับภายนอกแก้ปัญหาได้ง่ายกว่าและปลอดภัยกว่า อย่าประดิษฐ์พื้นที่เก็บข้อมูลของคุณเองโดยไม่จำเป็น

จะทำอย่างไรหากการรั่วไหลเกิดขึ้นแล้ว?

ดำเนินการตามลำดับ: เปลี่ยนรหัสผ่านพร็อกซีทันที เพิกถอนข้อมูลรับรองเก่า ค้นหาจุดรั่วไหลทั้งหมดด้วยสคริปต์ตรวจสอบ หากจำเป็น เขียนประวัติ git ใหม่ และวิเคราะห์สาเหตุเพื่อไม่ให้เกิดขึ้นซ้ำ

คำแนะนำเหล่านี้ใช้กับ runner บน Windows ได้หรือไม่?

ได้ หลักการเหมือนกัน ไวยากรณ์ต่างกัน: แทนที่จะใช้ export ให้ใช้วิธีตั้งค่าตัวแปรสำหรับเชลล์ของคุณ และแทน chmod ให้ตั้งค่าสิทธิ์ผ่านคุณสมบัติไฟล์ ตรรกะการจัดเก็บและการปิดล็อกเหมือนกัน

บทสรุป

คุณได้เดินทางจากนิสัยที่ไม่ปลอดภัยในการเขียนรหัสผ่านใน URL ไปจนถึงการปกป้องข้อมูลรับรองพร็อกซีใน CI/CD อย่างสมบูรณ์ มาทบทวนสิ่งที่ทำไป

คุณเรียนรู้ที่จะจดจำห้าจุดที่รั่วไหลและเลิกใช้รหัสผ่านในที่อยู่พร็อกซี ย้ายข้อมูลรับรองไปยังตัวแปรสภาพแวดล้อมและไฟล์ netrc, curlrc และคอนฟิกไคลเอนต์ที่มีสิทธิ์ 600 ตั้งค่าความลับใน GitHub Actions, GitLab CI และ Jenkins พร้อมการมาสก์และการจำกัดขอบเขต ปิดล็อกโดยละเอียดที่พิมพ์ส่วนหัวการอนุญาตใน curl, Python requests และ Node เชี่ยวชาญการหมุนเวียนรหัสผ่านโดยไม่หยุด build และรวบรวมสคริปต์ตรวจสอบการรั่วไหลสำเร็จรูป สุดท้าย ผ่านรายการตรวจสอบขั้นสุดท้ายก่อนนำออกใช้

สิ่งที่ต้องทำต่อไป นำรายการตรวจสอบไปใช้เป็นขั้นตอนบังคับในการรีวิวไปป์ไลน์ทั้งหมดที่ใช้พร็อกซี Proxeon เพิ่ม job ตรวจสอบการรั่วไหลในทุกโปรเจกต์ ค่อย ๆ เปลี่ยนไปใช้ตัวจัดการความลับภายนอกและโทเค็นอายุสั้นเมื่อกระบวนการพื้นฐานเป็นนิสัย

จะพัฒนาต่ออย่างไร ศึกษาแนวปฏิบัติการจัดการความลับในระดับองค์กร การหมุนเวียนอัตโนมัติ และการตรวจสอบความผิดปกติบนบัญชีพร็อกซี ความปลอดภัยของข้อมูลรับรองไม่ใช่การตั้งค่าเพียงครั้งเดียว แต่เป็นวินัยทางวิศวกรรมที่ต่อเนื่อง แต่ตอนนี้คุณมีพื้นฐานที่มั่นคงสำหรับสร้างสิ่งอื่น ๆ ได้ ขอให้ build ปลอดภัยและประสบความสำเร็จ