LEVEL 2 · ระดับกลาง
Secrets & ตัวแปร
pipeline ที่ deploy จริงต้องใช้ความลับ: รหัส API, token, รหัสฐานข้อมูล แต่ความลับเหล่านี้ ห้ามอยู่ในโค้ดเด็ดขาด เพราะทุกอย่างใน Git ถูกบันทึกถาวรและกระจายไปทุก clone (จำคำเตือนเรื่อง .env ในบทที่ 3 ของเล่ม Git ได้ไหม) บทนี้คือวิธีจัดการความลับให้ถูกต้อง
8.1 ตัวแปรกับความลับ — ต่างกันที่ "ความไว"
| Variable (ตัวแปรธรรมดา) | Secret (ความลับ) | |
|---|---|---|
| เก็บอะไร | ค่าที่ไม่ลับ เช่น ชื่อ environment, region, ระดับ log | ค่าที่รั่วไม่ได้ เช่น token, รหัสผ่าน, private key |
| มองเห็นไหม | เห็นในล็อกได้ตามปกติ | ถูก mask เป็น *** ในล็อกอัตโนมัติ |
| เก็บที่ไหน | ในไฟล์ YAML หรือ settings ก็ได้ | ใน secret store ของแพลตฟอร์มเท่านั้น |
8.2 ใช้ secret อย่างถูกวิธี
คุณตั้งค่า secret ไว้ใน settings ของ repo (ไม่ใช่ในไฟล์) แล้วอ้างถึงด้วยไวยากรณ์พิเศษ — ค่าจริงจะถูกฉีดเข้ามาตอนรันเท่านั้น และถูกปิดบังในล็อก:
steps:
- run: ./deploy.sh
env:
API_TOKEN: ${{ secrets.API_TOKEN }} # ดึงจาก secret store, mask อัตโนมัติ
DB_PASSWORD: ${{ secrets.DB_PASSWORD }}กลไกการ mask สำคัญมาก: ต่อให้สคริปต์ของคุณเผลอ echo ค่า secret ออกมา แพลตฟอร์มจะแทนที่ด้วย *** ในล็อกให้ก่อนแสดง — เป็นตาข่ายกันพลาดชั้นสุดท้าย (แต่อย่าพึ่งมันแทนความระมัดระวัง)
8.3 ขอบเขตและการสืบทอด
แพลตฟอร์มสมัยใหม่ให้ตั้ง secret ได้หลายระดับ: ระดับ organization (ใช้ร่วมหลาย repo), ระดับ repo, และระดับ environment (เช่น secret ของ production แยกจาก staging — บทที่ 10) หลักคือ ให้สิทธิ์น้อยที่สุดเท่าที่จำเป็น: secret ของ production ไม่ควรเข้าถึงได้จาก pipeline ของ branch ทดลอง
✅ สรุปบทที่ 8 — ความลับห้ามอยู่ในโค้ด/Git เด็ดขาด · variable = ค่าไม่ลับ (เห็นในล็อกได้), secret = ค่าไว (mask เป็น
***อัตโนมัติ เก็บใน secret store) · อ้างด้วย${{ secrets.X }}ฉีดเข้าตอนรันเท่านั้น · ตั้ง secret หลายระดับและให้สิทธิ์น้อยที่สุด · ระวัง PR จาก fork เข้าถึง secret — ช่องโหว่ pwn request