คุณจัดการ secrets ใน CI/CD pipeline อย่างไร?

Question

Accepted Answer

CI/CD pipeline ต้องการ **secrets** (API keys, deployment credentials, รหัสผ่านฐานข้อมูล, tokens) เพื่อ build และ deploy แต่การจัดการอย่างไม่ปลอดภัยเป็นความเสี่ยงร้ายแรง **การจัดการ secrets** ที่เหมาะสมทำให้ credentials ปลอดภัยตลอด pipeline

## ปัญหา: secrets ต้องไม่ถูกเปิดเผยเด็ดขาด

```text
Pipelines need credentials, but secrets are a major security risk if mishandled:
  ⚠️ NEVER hardcode secrets in code, pipeline config files, or commit them to Git
     (committed secrets are exposed in history — even if "removed" later)
  ⚠️ NEVER print secrets in logs (pipeline logs may be visible/stored)
→ Leaked CI/CD secrets (deploy keys, cloud credentials) can compromise entire systems.
```

## การจัดการ secrets ที่เหมาะสม

```text
✓ Use the CI/CD platform's SECRETS STORE — encrypted secrets injected as env vars at
  runtime (GitHub Actions Secrets, GitLab CI variables, etc.) — NOT in the config file
✓ Use dedicated SECRETS MANAGERS — HashiCorp Vault, AWS Secrets Manager, etc.
  (fetch secrets at runtime; centralized, audited, rotatable)
✓ Reference secrets by NAME in the pipeline; the platform injects the value securely:
```

```yaml
# GitHub Actions: reference a secret (stored encrypted in the repo settings)
steps:
  - run: ./deploy.sh
    env:
      API_KEY: ${{ secrets.API_KEY }}   # injected securely, not hardcoded, masked in logs
```

## แนวปฏิบัติที่ดี

```text
✓ LEAST PRIVILEGE — pipeline credentials should have only the permissions needed
✓ Prefer short-lived/temporary credentials (e.g. OIDC to assume a cloud role — no
  long-lived keys stored at all)
✓ ROTATE secrets regularly; rotate IMMEDIATELY if leaked
✓ Mask secrets in logs (platforms do this for stored secrets); audit secret access
✓ Separate secrets per environment (dev/staging/prod)
```

## ทำไมจึงสำคัญ

การเข้าใจวิธีจัดการ secrets ใน CI/CD pipeline มีความสำคัญ เพราะ **การจัดการ secrets เป็นข้อกังวลด้านความปลอดภัยที่สำคัญยิ่ง** และ pipeline จัดการกับ credentials ที่ทรงพลัง ซึ่งหากรั่วไหลสามารถทำให้ทั้งระบบถูกบุกรุก จึงเป็นความรู้ด้านความปลอดภัยที่จำเป็น

pipeline ต้องการ secrets (API keys, deployment credentials, รหัสผ่านฐานข้อมูล) เพื่อ build และ deploy แต่การจัดการอย่างผิดพลาดเป็น **ความเสี่ยงด้านความปลอดภัยที่ร้ายแรงและพบบ่อย**

การเข้าใจกฎพื้นฐาน คือ **อย่า hardcode secrets ในโค้ดหรือ pipeline config อย่า commit ลง Git เด็ดขาด** (ที่ซึ่งมันถูกเปิดเผยในประวัติ แม้จะ "ลบ" ออกในภายหลัง) และ **อย่า print มันใน logs เด็ดขาด** เป็นสิ่งจำเป็น เพราะข้อผิดพลาดเหล่านี้ทำให้เกิดการรั่วไหลของ credential ที่จริงและสร้างความเสียหาย (deployment keys หรือ cloud credentials ที่รั่วสามารถทำให้ทั้งระบบถูกบุกรุก)

การเข้าใจ **การจัดการ secrets ที่เหมาะสม** ได้แก่ การใช้ **secrets store ที่เข้ารหัส** ของ CI/CD platform (inject secrets เป็น environment variables ตอน runtime แทนที่จะเก็บไว้ใน config) การใช้ **secrets managers** เฉพาะทาง (Vault, AWS Secrets Manager สำหรับ secrets ที่รวมศูนย์ ตรวจสอบได้ และหมุนเวียนได้) และการอ้างอิง secrets ด้วยชื่อเพื่อให้ platform inject ค่าอย่างปลอดภัย (และ mask มันใน logs) เป็นความรู้ในทางปฏิบัติที่จำเป็นสำหรับการรักษา credentials ให้ปลอดภัย

การเข้าใจ **แนวปฏิบัติที่ดี** ได้แก่ **least privilege** (credentials ของ pipeline มีเฉพาะ permission ที่จำเป็น จำกัด blast radius) การเลือกใช้ **credentials ที่มีอายุสั้น/ชั่วคราว** (เช่น OIDC เพื่อ assume cloud roles หลีกเลี่ยงการเก็บ key อายุยาวโดยสิ้นเชิง เป็นแนวปฏิบัติที่ดีสมัยใหม่) การ **หมุนเวียน** secrets เป็นประจำและทันทีหากรั่วไหล และการแยก secrets ตาม environment สะท้อนแนวปฏิบัติ pipeline ที่ปลอดภัยและสมบูรณ์

เนื่องจาก CI/CD pipeline จัดการกับ credentials ที่ทรงพลังซึ่งการรั่วไหลสามารถทำให้ระบบถูกบุกรุก และเนื่องจากการจัดการ secrets ที่เหมาะสม (ไม่ hardcode/commit/log secrets การใช้ secrets stores/managers least privilege และ credentials อายุสั้น) เป็นสิ่งจำเป็นในการป้องกันการละเมิดที่ร้ายแรง การเข้าใจวิธีจัดการ secrets ใน CI/CD จึงเป็นความรู้ที่สำคัญและวิกฤตด้านความปลอดภัยสำหรับการสร้าง pipeline ที่ปลอดภัย เป็นพื้นที่ที่มีความเสี่ยงสูงซึ่งแนวปฏิบัติที่เหมาะสมป้องกันการรั่วไหลของ credential ที่เป็นความเสี่ยงจริงและสร้างความเสียหายในการส่งมอบอัตโนมัติ