Security & Access Control ใน Monorepo

TL;DR

• Monorepo จำกัดสิทธิ์แยกโฟลเดอร์ไม่ได้จริง → ต้องใช้กระบวนการ/CI เข้ามาช่วย
• ใช้ CODEOWNERS, Branch Protection, และ PR Review เป็นแนวป้องกันระดับแรก
• วางแผนแยก Multi-repo เมื่อทีมโต (ตาม ownership)
• ใช้ private npm registry เพื่อแชร์ package อย่างปลอดภัย
• จัดการ Secrets แยกตามแอป และเก็บไว้ใน Vercel / GitHub Actions ไม่ hardcoded

---

1. ปัญหา: Monorepo ≠ Access Control แยกโฟลเดอร์

• Git ไม่สามารถกำหนด permission ให้เฉพาะโฟลเดอร์ภายใน repo ได้

• คนที่มีสิทธิ์ pull/push repo → เห็นทุกโฟลเดอร์

• ส่งผลเมื่อ:

  • อยากให้บางคนดูแลแค่ packages/ui-kit
  • ต้องซ่อน config บางส่วน เช่น production env

---

2. แนวทางการควบคุมที่ใช้ได้ในตอนนี้

✅ ใช้ CODEOWNERS

• บังคับให้ PR ที่แก้โฟลเดอร์นั้น ๆ ต้องมีผู้ดูแลตรวจ
• ตัวอย่าง:

# web app
/apps/web/            @dev-a
/apps/admin-dashboard/ @dev-b

# shared
/packages/ui-kit/     @dev-a

❗ ไม่ป้องกันการ clone หรือ push ตรง (แค่ควบคุมผ่าน PR)

---

✅ ตั้ง Branch Protection

• ตั้ง rule บน GitHub:

  • Require pull request review
  • Require status checks to pass (lint, test)
  • Block force push

• ตัวอย่างการตั้งบน branch main, dev:

  - ✅ Require at least 1 review
  - ✅ Require status checks: CI Lint, CI Build
  - ❌ Allow bypass
  

---

✅ ใช้ GitHub Actions แยก workflow ตาม scope

• กำหนดเฉพาะแพ็กเกจ/แอปที่ต้อง build หรือ test:

on:
  push:
    paths:
      - 'apps/web/**'

• ไม่รัน workflow ที่ไม่เกี่ยว → ลดความเสี่ยงจาก side effect

---

3. แนวทางกลาง-ยาว: แยก Multi-repo ตาม ownership

🌱 แผนการ Migration

Phase	ทำอะไร	เหมาะเมื่อทีม...
1	แยก packages/* ที่มีเจ้าของชัดเจน	≥ 3 dev, มีทีมย่อยแล้ว
2	แยก apps/* ไปเป็น repo แยก	Dev ไม่ดูแลข้ามแอป
3	ตั้ง CI sync & version control ข้าม repo	เริ่มมี release cycle ต่างกัน

⚙️ เทคโนโลยีประกอบ

• ใช้ GitHub Actions + Turborepo + git submodules หรือ git subtree
• จัด package เป็น private registry (ดูหัวข้อถัดไป)

---

4. การใช้ Private NPM Registry

🛡 ทำไมควรใช้

• แชร์ code จาก packages/* โดยไม่เปิด public
• ลดการ clone ทั้ง Monorepo สำหรับ dev บางคนหรือ 3rd party
• Version control ชัด (publish แบบ semver)

🧰 วิธีที่แนะนำ

วิธี	รายละเอียด	ข้อดี	ข้อจำกัด
GitHub Packages	@nokfa/ui-kit เป็นต้น	ทำงานร่วม GitHub Actions	ต้อง auth ก่อนติดตั้ง
Vercel Packages	ใช้ได้เฉพาะระบบ Vercel internal	ติดตั้งเร็วใน pipeline	ใช้แค่ในระบบ Vercel
Verdaccio	Private NPM server local	ควบคุมได้หมด	ต้องดูแล infra เอง

🔐 ตัวอย่าง publish ด้วย GitHub Packages

📄 .npmrc

@nokfa:registry=https://npm.pkg.github.com
//npm.pkg.github.com/:_authToken=${NPM_TOKEN}

📄 package.json

{
  "name": "@nokfa/ui-kit",
  "version": "1.2.3",
  "publishConfig": {
    "registry": "https://npm.pkg.github.com/"
  }
}

$ npm publish

ต้องใช้ NPM_TOKEN จาก GitHub → เก็บใน Secret

---

5. Secrets Management ที่ปลอดภัย

❌ หลีกเลี่ยง

• ห้าม commit .env.* ลง git
• ห้าม hardcode key หรือ token ไว้ในโค้ด

✅ วิธีที่แนะนำ

ระบบ	วิธีเก็บ	จุดเด่น
Vercel	Project → Settings → Environment	UI ใช้งานง่าย, Scope ตามแอป
GitHub Actions	Repository → Settings → Secrets	ใช้ใน workflow เช่น deploy key
dotenv-vault	แชร์ env ข้ามเครื่องอย่างปลอดภัย	เหมาะสำหรับ dev local หลายคน

🔐 ตัวอย่างเรียกใช้ secret ใน workflow

env:
  FIREBASE_ADMIN_KEY: ${{ secrets.FIREBASE_ADMIN_KEY }}

---

6. Summary Table

หัวข้อ	ใช้ใน Monorepo	ใช้ใน Multi-repo
จำกัดสิทธิ์ต่อโฟลเดอร์	❌ ไม่ได้	✅ ทำได้
CODEOWNERS	✅ ได้บางส่วน	✅ ได้เต็มที่
CI Scope	✅ ทำได้	✅ ทำได้
Publish แพ็กเกจ	✅ ผ่าน Monorepo หรือ Registry	✅ ผ่าน registry
ซ่อน Secrets	✅ ผ่าน Vercel / GH Secrets	✅ เหมือนกัน

---

7. ข้อแนะนำเมื่อเริ่มมี Dev > 2

• ⚠ สื่อสารให้ชัดว่า "โฟลเดอร์ใครรับผิดชอบอะไร"
• ✅ เขียน README.md ในแต่ละ package/app อธิบายการใช้งาน
• ✅ เพิ่ม reviewer ตาม scope (อิง CODEOWNERS)
• ✅ ปรับ Workflow CI ให้เฉพาะทาง (ลด shared failure)
• ✅ ถ้า dev คนอื่น clone ได้หมด → ต้องมี Security Review ก่อนรวมโค้ด