NVIDIA OpenShell คืออะไร? คู่มือเริ่มต้นใช้งาน Sandbox สำหรับรัน AI Agent อย่างปลอดภัย

NVIDIA OpenShell คืออะไร? คู่มือเริ่มต้นใช้งาน Sandbox สำหรับรัน AI Agent อย่างปลอดภัย

บทนำ

NVIDIA OpenShell คือสภาพแวดล้อมการทำงาน (Runtime) แบบโอเพนซอร์สที่ออกแบบมาเพื่อรัน AI Agent ภายใน Sandbox อย่างปลอดภัย โดยป้องกันไม่ให้ Agent เข้าถึงไฟล์หรือข้อมูลรับรอง (Credentials) ของโฮสต์โดยตรง พร้อมทั้งควบคุมการเข้าถึงเครือข่ายภายนอกผ่านนโยบายแบบประกาศ (Declarative Policy) และสามารถติดตามการดำเนินการที่ได้รับอนุญาตหรือถูกปฏิเสธผ่านบันทึก (Log) ได้

บทความนี้จัดทำขึ้นสำหรับนักพัฒนาและเจ้าหน้าที่ฝ่ายไอทีที่ต้องการทดลองใช้งาน Coding Agent เช่น Claude Code อย่างปลอดภัย โดยจะอธิบายขั้นตอนตั้งแต่การติดตั้ง OpenShell การสร้าง Sandbox ครั้งแรก ไปจนถึงการควบคุมการเข้าถึงด้วยนโยบาย ตามเอกสารอย่างเป็นทางการ (github.com/NVIDIA/OpenShell, ลิขสิทธิ์ Apache 2.0) เมื่ออ่านจบ คุณจะสามารถสร้างสภาพแวดล้อมขั้นต่ำเพื่อรัน Agent โดยแยกออกจากโฮสต์ในระบบของคุณเองได้

OpenShell คือแซนด์บ็อกซ์แบบเน้นนโยบาย (policy-driven sandbox) ที่ออกแบบมาโดยมีสมมติฐานว่าเป็น "เอเจนต์ที่ทำงานไปพร้อมกับการเขียนทับสภาพแวดล้อมการทำงานของตัวเอง" ก่อนอื่น เรามาสรุปความแตกต่างจากคอนเทนเนอร์ทั่วไปและสิ่งที่ระบบนี้ช่วยปกป้องกันก่อน

ความแตกต่างจากคอนเทนเนอร์ทั่วไป

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

ในทางกลับกัน AI Agent จะทำการเปลี่ยนแปลงสภาพแวดล้อมการทำงานของตัวเองอยู่ตลอดเวลา ทั้งการเขียนโค้ด การติดตั้งแพ็กเกจ และการแก้ไขไฟล์ตั้งค่า OpenShell จึงมีความแตกต่างตรงที่ได้จัดเตรียมพื้นที่แยกส่วน (Isolated space) เพื่อให้เอเจนต์เหล่านี้สามารถลองผิดลองถูกได้อย่างปลอดภัย โดยตั้งอยู่บนสมมติฐานที่ว่า "เอเจนต์จะมีการเปลี่ยนแปลงสภาพแวดล้อมอยู่เสมอ"

ในเชิงปฏิบัติ OpenShell จะอนุญาตเฉพาะการดำเนินการที่จำเป็นสำหรับเอเจนต์เท่านั้น และจะปิดกั้นการดำเนินการอื่น ๆ (เช่น การอ่านไฟล์ของโฮสต์, การเข้าถึงข้อมูลรับรอง (Credentials), หรือการสื่อสารไปยังภายนอกที่ไม่ได้รับอนุญาต) ในระดับ OS หากคอนเทนเนอร์เน้นไปที่ "การแยกแอปพลิเคชัน" เป็นหลัก OpenShell ก็จะเน้นไปที่ "การจำกัดสิทธิ์ของเอเจนต์ให้เหลือน้อยที่สุด" (Principle of Least Privilege) แทน

4 โดเมนการป้องกัน (ไฟล์, เครือข่าย, กระบวนการ, การอนุมาน)

จุดเด่นที่สุดของ OpenShell คือการบังคับใช้แบบ "Out-of-process" ซึ่งเป็นการกำหนดข้อจำกัดไว้ที่ตัวสภาพแวดล้อมที่เอเจนต์ทำงานอยู่ แทนที่จะควบคุมเอเจนต์ด้วยพรอมต์ (คำสั่งการทำงาน) เนื่องจากข้อจำกัดเหล่านี้ทำงานจากภายนอกตัวเอเจนต์ แม้ว่าเอเจนต์จะถูกบุกรุกก็ไม่สามารถเขียนทับข้อจำกัดเหล่านั้นได้ด้วยตัวเอง

เอกสารอย่างเป็นทางการได้ระบุภัยคุกคามที่ต้องป้องกันไว้ 4 ประการ โดยมี Policy domain รองรับแต่ละด้านดังนี้:

  • Filesystem (ระบบไฟล์): ป้องกันการอ่าน SSH key หรือข้อมูลรับรองบนคลาวด์ (การขโมยข้อมูลรับรอง) โดยใช้ Landlock ของ Linux kernel ในการปิดกั้นการอ่านและเขียนในเส้นทางที่ไม่ได้รับอนุญาต และจะถูกล็อกไว้เมื่อสร้างแซนด์บ็อกซ์
  • Network (เครือข่าย): ป้องกันการส่งซอร์สโค้ดหรือไฟล์ภายในบริษัทออกสู่ภายนอก (การนำข้อมูลออก) โดยจะปฏิเสธการสื่อสารขาออกไปยังปลายทางที่ไม่ได้รับอนุญาต และสามารถทำ Hot reload ได้ในขณะที่ระบบกำลังทำงาน
  • Process (กระบวนการ): ป้องกันการยกระดับสิทธิ์ผ่าน sudo หรือ setuid โดยใช้ Process ID ที่ไม่มีสิทธิ์และ seccomp ในการจำกัด System call ที่เป็นอันตราย ซึ่งจะถูกล็อกไว้ตั้งแต่ตอนสร้าง
  • Inference (การอนุมาน): ป้องกันการส่งข้อมูลไปยังผู้ให้บริการโมเดลที่ไม่ได้รับอนุญาต โดยทำหน้าที่เป็น "privacy router" ที่เก็บข้อมูลบริบทที่เป็นความลับไว้ในโมเดลแบบเปิด (Open model) ภายในเครื่อง และจะส่งต่อไปยัง Frontier model เช่น Claude หรือ GPT ก็ต่อเมื่อนโยบายอนุญาตเท่านั้น

นโยบายจะถูกเขียนด้วย YAML แบบประกาศ (Declarative) โดยส่วนที่คงที่ (Filesystem และ Process) จะถูกล็อกไว้ตั้งแต่ตอนสร้าง ส่วนส่วนที่เปลี่ยนแปลงได้ (Network และ Inference) สามารถอัปเดตได้โดยไม่ต้องรีสตาร์ทระบบ

เอเจนต์ที่รองรับและไลเซนส์

OpenShell ได้รับการออกแบบมาให้เป็นสภาพแวดล้อมการทำงานแบบอเนกประสงค์ที่ไม่ขึ้นกับเอเจนต์เฉพาะตัว ในคู่มือเริ่มต้นใช้งานฉบับทางการ (Quickstart) ผู้ใช้สามารถเลือกเป้าหมายการรันได้หลากหลาย เช่น "Claude Code", "Codex" หรือ "OpenCode" เป็นต้น เนื่องจาก CLI สามารถตรวจหาข้อมูลรับรอง (Credentials) ของเอเจนต์ที่รู้จักได้โดยอัตโนมัติจากสภาพแวดล้อมเชลล์ ในหลายกรณีจึงสามารถนำไปรันในแซนด์บ็อกซ์ได้ทันทีโดยไม่ต้องแก้ไขโค้ด

OpenShell เป็นซอฟต์แวร์โอเพนซอร์สภายใต้สัญญาอนุญาต Apache 2.0 โดยซอร์สโค้ดเปิดเผยอยู่ที่ github.com/NVIDIA/OpenShell ณ เวลาที่เขียนบทความนี้ ซอฟต์แวร์ยังอยู่ในช่วงเริ่มต้นของเวอร์ชัน 0.0.x ซึ่งโครงสร้างคำสั่งและสคีมานโยบาย (Policy Schema) อาจมีการเปลี่ยนแปลงได้ในอนาคต หากต้องการใช้งานจริง โปรดตรวจสอบข้อมูลจำเพาะล่าสุดจากเอกสารอย่างเป็นทางการ (docs.nvidia.com/openshell) เสมอ

สิ่งที่ต้องเตรียม — 4 ข้อกำหนดเบื้องต้น

การทดลองใช้งาน OpenShell จำเป็นต้องมีองค์ประกอบ 4 ประการ ได้แก่ ระบบปฏิบัติการที่รองรับ, สภาพแวดล้อมการรันคอนเทนเนอร์, CLI และข้อมูลรับรอง (Credentials) ของเอเจนต์ โดยจะตรวจสอบแต่ละรายการตามลำดับดังนี้

ระบบปฏิบัติการและสภาพแวดล้อมการรันคอนเทนเนอร์ที่รองรับ

การใช้งาน OpenShell จำเป็นต้องมีสภาพแวดล้อมดังต่อไปนี้:

  • macOS / Linux / Windows + WSL 2 อย่างใดอย่างหนึ่ง
  • สามารถใช้งาน Docker / Podman / MicroVM อย่างใดอย่างหนึ่งได้
  • OpenShell CLI และ OpenShell gateway

เนื่องจากการแยกส่วนระบบไฟล์ (Filesystem isolation) ใช้ Landlock ของ Linux kernel ดังนั้นสภาพแวดล้อม Linux (รวมถึง WSL 2 และคอนเทนเนอร์ที่ทำงานบน Linux kernel) จึงสามารถใช้ฟังก์ชันการป้องกันได้อย่างเต็มประสิทธิภาพ สำหรับ macOS จะทำงานผ่านเลเยอร์การจำลองเสมือน (Virtualization layer) ทั้งนี้ สำหรับองค์กรมีการแนะนำการตั้งค่าที่รันเอเจนต์แบบทำงานต่อเนื่องยาวนานบน DGX Spark ด้วยเช่นกัน

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

บัญชีเอเจนต์และ API Key

บัญชีและ API Key สำหรับเอเจนต์ที่ทำงานภายในแซนด์บ็อกซ์ (เช่น Claude Code) จำเป็นต้องมีการเตรียมไว้แยกต่างหาก OpenShell เป็นเพียงเครื่องมือสำหรับแยกส่วนเอเจนต์อย่างปลอดภัยเท่านั้น ไม่ได้ให้สิทธิ์ในการใช้งานเอเจนต์แต่อย่างใด

OpenShell CLI จะตรวจหาข้อมูลประจำตัว (Credentials) ของเอเจนต์ที่รู้จัก (เช่น Claude, Codex, OpenCode, Copilot ฯลฯ) จากตัวแปรสภาพแวดล้อม (Environment Variables) ของเชลล์โดยอัตโนมัติ ซึ่งหมายความว่าคุณสามารถส่งผ่านข้อมูลการยืนยันตัวตนที่ใช้งานอยู่บนโฮสต์ตามปกติได้ทันที นอกจากนี้ยังสามารถลงทะเบียนข้อมูลประจำตัว (Provider) อย่างชัดเจนได้เช่นกัน

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

ขั้นตอนที่ 1 — ติดตั้ง OpenShell และตรวจสอบการเชื่อมต่อ

การติดตั้งสามารถทำได้ด้วยสคริปต์ทางการเพียงคำสั่งเดียว ซึ่งจะติดตั้งทั้ง CLI และ Gateway ให้พร้อมกัน หลังจากติดตั้งเสร็จแล้ว ให้ตรวจสอบการเชื่อมต่อด้วยคำสั่ง status และ help

การติดตั้ง CLI และ Gateway

ดำเนินการติดตั้งสคริปต์อย่างเป็นทางการ

bash
1curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh

สคริปต์นี้จะทำการติดตั้ง "OpenShell CLI" และ "OpenShell gateway" พร้อมทั้งเริ่มการทำงานของเกตเวย์ในเครื่องโดยอัตโนมัติ โดย CLI จะทำหน้าที่เป็นช่องทางในการสั่งการ ส่วน gateway จะเป็นคอมโพเนนต์แบบ常駐 (resident) ที่ทำหน้าที่ enforce (บังคับใช้) แซนด์บ็อกซ์และนโยบายเครือข่ายจริง ทั้งนี้ ในเอกสารอย่างเป็นทางการยังได้แนะนำวิธีการติดตั้งผ่านคำสั่ง uv tool install -U openshell อีกด้วย

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

ตรวจสอบการเชื่อมต่อด้วย status และ help

หลังจากติดตั้งเสร็จสิ้น ให้ตรวจสอบสถานะของเกตเวย์

bash
1openshell status

หากการทำงานเป็นปกติ ระบบจะแสดงชื่อเกตเวย์, URL ของเซิร์ฟเวอร์ (ตัวอย่างเช่น ที่อยู่ภายในเครื่องอย่าง https://127.0.0.1:17670), สถานะการเชื่อมต่อ (Connected) และเวอร์ชัน หากปรากฏสถานะเป็น Connected แสดงว่า CLI สามารถเชื่อมต่อกับเกตเวย์ได้แล้ว

สามารถตรวจสอบรายการคำสั่งย่อยที่ใช้งานได้โดยใช้คำสั่ง help

bash
1openshell --help

หากสถานะ status ไม่แสดงเป็น Connected ให้ตรวจสอบว่ากระบวนการ (process) ของเกตเวย์ทำงานอยู่หรือไม่ หรือพอร์ตภายในเครื่องเกิดการชนกับกระบวนการอื่นหรือไม่ การตรวจสอบการเชื่อมต่อในขั้นตอนนี้จะช่วยให้แยกแยะปัญหาได้ง่ายขึ้นในภายหลังเมื่อสร้าง Sandbox ว่าเป็น "ปัญหาที่ตัว CLI หรือปัญหาที่นโยบาย (policy)"

ขั้นตอนที่ 2 — สร้าง Sandbox แรก

ขั้นตอนที่ 2 — สร้าง Sandbox แรก

การใช้งานพื้นฐานของ OpenShell คือการสร้าง Sandbox ด้วยคำสั่ง openshell sandbox create แล้วจึงรัน Agent ภายในนั้น ต่อไปเราจะลองใช้งาน Claude Code ในสภาพแวดล้อมที่ถูกแยกส่วน (Isolated environment) กันดู

การเรียกใช้งาน claude ภายใน Sandbox

สร้าง Sandbox โดยตั้งชื่อและเรียกใช้งาน Claude Code ภายในนั้น

bash
1openshell sandbox create --name demo -- claude

--name demo คือการตั้งชื่อ Sandbox ว่า "demo" และ claude ที่ส่งต่อหลัง -- จะถูกเรียกใช้งานภายใน Sandbox เมื่อเริ่มต้นทำงาน Claude Code จะเริ่มทำงานภายใน Sandbox ดังกล่าว

-- คือตัวคั่นที่หมายถึง "คำสั่งต่อจากนี้จะให้รันภายใน Sandbox" นอกจาก Claude Code แล้ว คุณยังสามารถเรียกใช้งานเอเจนต์อื่นที่ CLI รองรับในรูปแบบเดียวกันได้ เช่น Codex หรือ OpenCode เนื่องจากข้อมูลการยืนยันตัวตนของเอเจนต์จะถูกตรวจพบโดยอัตโนมัติจากสภาพแวดล้อมโฮสต์ ในหลายกรณีคุณจึงสามารถเริ่มใช้งานได้ทันทีโดยไม่ต้องตั้งค่าเพิ่มเติม

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

ตรวจสอบให้แน่ใจว่าเอเจนต์ที่เปิดใช้งานอยู่นั้นทำงานภายใน Sandbox ไม่ใช่บนโฮสต์ ตัวอย่างเช่น ลองถาม Claude Code เกี่ยวกับไดเรกทอรีปัจจุบัน

พาธสัมบูรณ์ของโฟลเดอร์ปัจจุบันคืออะไร?

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

การตรวจสอบว่า "กำลังทำงานอยู่ที่ไหน" เป็นขั้นตอนที่เรียบง่ายแต่สำคัญ ก่อนที่จะมอบหมายงานด้านการจัดการไฟล์หรือการรันคำสั่งให้กับเอเจนต์ คุณควรตรวจสอบด้วยตาตนเองก่อนว่ามันถูกแยกออกจากสภาพแวดล้อมของโฮสต์แล้ว หากข้ามขั้นตอนนี้ไป อาจนำไปสู่ความผิดพลาดที่คิดว่าถูกแยกส่วนอยู่ แต่จริงๆ แล้วกลับกำลังเข้าถึงโฮสต์อยู่ก็ได้

สั่งงานเอเจนต์และตรวจสอบผลลัพธ์

เมื่อ Sandbox เริ่มทำงานแล้ว ให้ลองมอบหมายงานง่ายๆ ให้กับ Agent ตัวอย่างเช่น สั่งดังนี้:

hello_world.py を作成してください。

Agent จะสร้างไฟล์ขึ้นภายใน Sandbox หากต้องการตรวจสอบโค้ดที่สร้างขึ้น ให้ใช้ /exit เพื่อออกจาก Claude Code แล้วดูเนื้อหาใน Shell ของ Sandbox:

bash
1sandbox@xxxx:~$ pwd 2/sandbox 3sandbox@xxxx:~$ ls 4hello_world.py 5sandbox@xxxx:~$ cat hello_world.py 6print("Hello, World!")

เมื่อทำงานเสร็จแล้ว ให้ใช้ exit เพื่อออกจาก Shell ของ Sandbox และกลับสู่ Shell ของเครื่องโฮสต์ ไฟล์ที่ Agent สร้างขึ้นจะถูกแยกไว้ภายใต้ /sandbox และไม่ทำให้โครงสร้างไฟล์ของเครื่องโฮสต์ปนเปื้อน สภาวะที่ "ผลลัพธ์ถูกจำกัดอยู่ภายใน Sandbox" นี้เองที่เป็นรากฐานให้เราสามารถลองผิดลองถูกได้อย่างปลอดภัย

ขั้นตอนที่ 3 — การจัดการ Sandbox (รายการ, เชื่อมต่อใหม่, ลบ)

ขั้นตอนที่ 3 — การจัดการ Sandbox (รายการ, เชื่อมต่อใหม่, ลบ)

จัดการ Sandbox ที่สร้างขึ้นได้ผ่านการแสดงรายการ เชื่อมต่อใหม่ และลบ เมื่อการทดลองเสร็จสิ้น ให้ลบ Sandbox ที่ไม่จำเป็นออกเพื่อจัดระเบียบสภาพแวดล้อมให้เรียบร้อย

การใช้งาน list, connect และ delete

สามารถตรวจสอบรายการ Sandbox ได้ด้วยคำสั่งต่อไปนี้

bash
1openshell sandbox list

ระบบจะแสดงชื่อ (NAME), วันที่สร้าง (CREATED) และสถานะ (PHASE) หากเริ่มการทำงานแล้ว PHASE จะแสดงเป็น Ready (นอกจากนี้ยังมีสถานะอื่นๆ เช่น Provisioning, Error และ Deleting) คุณสามารถส่งออกข้อมูลในรูปแบบที่เครื่องอ่านได้โดยการเพิ่ม -o json หรือ -o yaml ต่อท้ายคำสั่ง

หากต้องการกลับเข้าไปใน Sandbox ที่มีอยู่ ให้ใช้คำสั่ง connect แล้วจึงเริ่มการทำงานของ Agent ภายในนั้น

bash
1openshell sandbox connect demo 2claude

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

bash
1openshell sandbox delete demo

โปรดทราบว่า connect เป็นเพียงการเชื่อมต่อเข้ากับเชลล์ของ Sandbox เท่านั้น ส่วนการเริ่มการทำงานของ Agent จะเป็นคนละขั้นตอนกัน หากต้องการตรวจสอบสถานะการทำงานโดยรวม สามารถใช้แดชบอร์ดของ openshell term ได้ ทั้งนี้ ไม่ควรทิ้ง Sandbox ไว้โดยไม่ใช้งาน และควรลบด้วย sandbox delete หลังจากตรวจสอบเสร็จสิ้น เพื่อป้องกันไม่ให้สถานะหรือนโยบายเก่าหลงเหลืออยู่ ซึ่งอาจทำให้การแยกแยะปัญหาในการทำงานทำได้ยากขึ้น

ขั้นตอนที่ 4 — การควบคุมการเข้าถึงเครือข่ายด้วยนโยบาย

ขั้นตอนที่ 4 — การควบคุมการเข้าถึงเครือข่ายด้วยนโยบาย

คุณค่าที่แท้จริงของ OpenShell อยู่ที่ความสามารถในการควบคุมการเข้าถึงเครือข่ายด้วยนโยบายแบบประกาศ (Declarative Policy) ในส่วนนี้ เราจะมาทดสอบการบล็อก URL ที่ไม่ได้รับอนุญาตตามค่าเริ่มต้น และดำเนินการแก้ไขนโยบายเพื่ออนุญาตให้เข้าถึงได้จนจบกระบวนการ

URL ที่ไม่ได้รับอนุญาตตามค่าเริ่มต้นจะถูกบล็อก

แซนด์บ็อกซ์ (Sandbox) เริ่มต้นด้วย "การเข้าถึงภายนอกขั้นต่ำ" โดยจะไม่สามารถเข้าถึง URL ที่ไม่ได้รับอนุญาตตามนโยบายเริ่มต้นได้

ขั้นแรก ให้เชื่อมต่อกับแซนด์บ็อกซ์

bash
1openshell sandbox connect demo

ลองใช้ curl เพื่อเข้าถึง URL ที่ไม่ได้รับอนุญาต

bash
1curl -I https://example.com/some-path

การสื่อสารไปยังโฮสต์ที่ไม่อยู่ในนโยบายเริ่มต้นจะถูกบล็อกโดยพร็อกซีของเกตเวย์ ซึ่งเป็นการปิดความเสี่ยงที่เอเจนต์จะส่งข้อมูลออกไปยังภายนอกโดยพลการ (การนำข้อมูลออก = exfiltration) ด้วยการตั้งค่า แนวคิดเรื่องสิทธิ์ขั้นต่ำที่ว่า "ปฏิเสธโดยค่าเริ่มต้น และอนุญาตเฉพาะสิ่งที่จำเป็นอย่างชัดเจนเท่านั้น" จึงถูกนำมาใช้ในระดับเครือข่ายด้วยเช่นกัน

การดึงข้อมูลและอ่านนโยบาย

ส่งออกนโยบายปัจจุบันไปยังไฟล์

bash
1openshell policy get demo --full > current-policy.yaml

ที่ส่วนต้นของไฟล์ที่ส่งออกมาจะมีข้อมูลเมตา เช่น Version Hash Status Active Created และตามด้วยตัวเนื้อหา YAML โดยมี --- เป็นตัวคั่น จากเนื้อหา YAML เราสามารถอ่านข้อมูลต่อไปนี้ได้:

  • สามารถเข้าถึงโฮสต์หรือ URL ใดได้บ้าง (network_policies)
  • อนุญาตให้เข้าถึงเครือข่ายจากคำสั่ง (ไบนารี) ใดได้บ้าง (binaries)
  • สามารถอ่าน/เขียนโฟลเดอร์ใดได้บ้าง (filesystem_policy)
  • รันกระบวนการ (process) ด้วยผู้ใช้/กลุ่มใด

เนื้อหา YAML มีโครงสร้างโดยประมาณดังนี้ (ส่วนหนึ่ง):

yaml
1version: 1 2filesystem_policy: 3 include_workdir: true 4 read_only: 5 - /usr 6 - /etc 7 read_write: 8 - /sandbox 9 - /tmp 10landlock: 11 compatibility: best_effort 12process: 13 run_as_user: sandbox 14 run_as_group: sandbox 15network_policies: 16 claude_code: 17 name: claude-code 18 endpoints: 19 - host: api.anthropic.com 20 port: 443 21 protocol: rest 22 tls: terminate 23 enforcement: enforce 24 access: full 25 binaries: 26 - path: /usr/local/bin/claude

การแก้ไขและปรับใช้นโยบาย

เพิ่มโฮสต์ที่ต้องการอนุญาตการเข้าถึงลงใน network_policies โดยกฎเหล็กคือต้อง "เพิ่ม" นโยบายใหม่เข้าไปโดยไม่ลบ network_policies เดิมทิ้ง เนื่องจากคำสั่ง openshell policy set จะเป็นการแทนที่นโยบายทั้งหมด ตัวอย่างเช่น หากต้องการเพิ่มสิทธิ์การเข้าถึงแบบอ่านอย่างเดียว (read-only) ไปยังโฮสต์ที่กำหนด ให้เพิ่มบล็อกดังต่อไปนี้ต่อท้ายนโยบายเดิม:

yaml
1 example_site: 2 name: example-site 3 endpoints: 4 - host: example.com 5 port: 443 6 protocol: rest 7 enforcement: enforce 8 access: read-only 9 binaries: 10 - path: /usr/bin/curl

ค่า enforcement ของแต่ละ endpoint สามารถเลือกได้ระหว่าง enforce ซึ่งจะบล็อกการละเมิดจริง กับ audit ซึ่งจะบันทึกข้อมูลโดยไม่บล็อกการทำงาน เพื่อความปลอดภัย แนะนำให้เลือกใช้ audit เพื่อสังเกตพฤติกรรมก่อน แล้วจึงเปลี่ยนเป็น enforce ในภายหลัง เนื่องจาก OpenShell ประเมินการเข้าถึงในระดับความละเอียดของ Binary, ปลายทาง, HTTP Method และ Path คุณจึงสามารถควบคุมการเข้าถึงได้อย่างละเอียด เช่น "อนุญาตให้ curl ทำได้เฉพาะ GET ไปยังโฮสต์นี้เท่านั้น"

ก่อนนำไปใช้ ต้องลบข้อมูลเมตา (เช่น Version / Hash / Status) ที่อยู่เหนือ --- ที่ส่วนหัวของไฟล์ออกให้หมด สิ่งที่จะส่งให้กับ policy set ต้องเป็นเนื้อหา YAML ที่อยู่หลัง --- เท่านั้น

bash
1openshell policy set demo --policy current-policy.yaml --wait

ตัวเลือก --wait คือการรอจนกว่าการปรับใช้จะเสร็จสมบูรณ์ เนื่องจาก Network Policy จะถูก Hot-reload เข้าสู่ Sandbox ที่กำลังทำงานอยู่ การเปลี่ยนแปลงจึงมีผลโดยไม่ต้องสร้าง Sandbox ใหม่ หลังจากปรับใช้แล้ว ให้ลองเชื่อมต่อใหม่และใช้ curl ไปยัง URL เดิม คุณจะพบว่าสามารถเข้าถึงได้แล้ว

ข้อผิดพลาดที่พบบ่อยและวิธีแก้ไข

ข้อผิดพลาดที่พบบ่อยและวิธีแก้ไข

นี่คือจุดที่มักจะเกิดข้อผิดพลาดได้ง่ายเมื่อเริ่มใช้งาน OpenShell พร้อมวิธีแก้ไข:

  • การใช้ policy set ทับนโยบายเดิมทั้งหมด: คำสั่ง policy set จะเป็นการแทนที่นโยบายทั้งหมด หากลบ network_policies เดิมออก อาจทำให้การสื่อสารที่จำเป็นสำหรับเอเจนต์ (เช่น Model API) หยุดทำงานได้ ดังนั้นควรใช้การแก้ไขโดยเพิ่มข้อมูลต่อท้ายจากเนื้อหาที่ดึงมาด้วย policy get เสมอ
  • การส่งข้อมูลที่มีเมทาดาตาติดไปด้วยใน policy set: หากทิ้งเมทาดาตา (เช่น Version / Hash) ที่อยู่เหนือ --- ไว้ จะทำให้การปรับใช้ล้มเหลว ต้องตัดให้เหลือเพียงเนื้อหาหลักก่อนส่งคำสั่ง
  • การพยายามเปลี่ยนนโยบายแบบ Static ในขณะที่กำลังทำงาน: filesystem และ process จะถูกล็อกไว้ตั้งแต่ตอนสร้างและไม่สามารถเปลี่ยนแปลงได้ในขณะที่กำลังทำงาน หากต้องการเปลี่ยนส่วนนี้จะต้องสร้าง Sandbox ใหม่ สิ่งที่สามารถทำ Hot reload ได้มีเพียง network และ inference เท่านั้น
  • การคาดหวังการป้องกันของ Landlock บน macOS: Landlock เป็นฟีเจอร์ของ Linux kernel ซึ่งจะมีพฤติกรรมแตกต่างกันไปตามสภาพแวดล้อม ดังที่เห็นได้จากการตั้งค่า compatibility: best_effort จึงควรทำความเข้าใจให้ชัดเจนว่าระบบจะป้องกันได้ถึงระดับใด
  • การปล่อย Sandbox ทิ้งไว้: หากปล่อย Sandbox หรือนโยบายเก่าๆ ทิ้งไว้ จะทำให้การแยกแยะพฤติกรรมทำได้ยาก หลังจากตรวจสอบเสร็จสิ้นแล้วควรล้างข้อมูลด้วย sandbox delete

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

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

รวมคำถามที่พบบ่อยเกี่ยวกับ OpenShell

Q. OpenShell แตกต่างจาก Docker ทั่วไปอย่างไร? ในขณะที่ Docker มีจุดประสงค์หลักเพื่อการแยกส่วน (Isolation) ของแอปพลิเคชัน แต่ OpenShell ออกแบบมาเพื่อการรัน "AI Agent ที่สามารถแก้ไขสภาพแวดล้อมของตัวเองขณะทำงาน" ได้อย่างปลอดภัย โดยมีการควบคุมผ่านนโยบาย (Policy) ใน 4 ด้าน ได้แก่ ไฟล์, เครือข่าย, กระบวนการ (Process) และการอนุมาน (Inference) ซึ่งจุดแตกต่างที่สำคัญคือ สามารถอัปเดตการตั้งค่าเครือข่ายและการอนุมานได้ในขณะที่ระบบกำลังทำงานอยู่

Q. จำเป็นต้องแก้ไขโค้ดของ Agent ที่มีอยู่หรือไม่? ในกรณีส่วนใหญ่ไม่จำเป็น CLI สามารถตรวจพบข้อมูลการยืนยันตัวตนของ Agent ที่รู้จัก (เช่น Claude, Codex, OpenCode ฯลฯ) ได้โดยอัตโนมัติ ทำให้สามารถรันภายใน Sandbox ได้โดยไม่ต้องแก้ไขโค้ด

Q. สามารถนำไปใช้ในสภาพแวดล้อมการทำงานจริง (Production) ได้หรือไม่? แม้จะเป็นซอฟต์แวร์โอเพนซอร์สภายใต้ใบอนุญาต Apache 2.0 แต่ ณ เวลาที่เขียนบทความนี้ ระบบยังอยู่ในช่วงเริ่มต้นเวอร์ชัน 0.0.x ซึ่งอาจมีการเปลี่ยนแปลงข้อมูลจำเพาะได้ หากพิจารณาจะนำไปใช้ในงานจริง ควรตรวจสอบแพลตฟอร์มที่รองรับและข้อจำกัดที่ทราบจากเอกสารอย่างเป็นทางการและบันทึกประจำรุ่น (Release Notes) ล่าสุด และเริ่มต้นจากการทดสอบในวงจำกัดจะปลอดภัยที่สุด

บทสรุป

บทสรุป

NVIDIA OpenShell คือสภาพแวดล้อมการทำงานแบบโอเพนซอร์สที่ช่วยให้สามารถรัน AI Agent ภายในแซนด์บ็อกซ์ได้อย่างปลอดภัย โดยสามารถปกป้องไฟล์และข้อมูลรับรอง (credentials) ของโฮสต์ พร้อมทั้งควบคุมการเข้าถึงเครือข่ายด้วยนโยบายแบบประกาศ (declarative policy) ในบทความนี้ เราได้ติดตามขั้นตอนตั้งแต่การติดตั้ง การตรวจสอบการเชื่อมต่อ การสร้างแซนด์บ็อกซ์แรก การมอบหมายงานให้เอเจนต์ ไปจนถึงการควบคุมเครือข่ายด้วยนโยบาย

ประเด็นสำคัญมี 3 ประการ ประการแรก OpenShell ออกแบบมาเพื่อรองรับ "เอเจนต์ที่เปลี่ยนแปลงสภาพแวดล้อม" โดยปกป้อง 4 ส่วนสำคัญ ได้แก่ ไฟล์ เครือข่าย กระบวนการ และการอนุมาน (inference) ด้วยหลักการสิทธิ์ขั้นต่ำ (least privilege) ประการที่สอง แซนด์บ็อกซ์สามารถจัดการได้ด้วยการดำเนินการที่เรียบง่าย คือ การสร้าง การเชื่อมต่อ และการลบ โดยผลลัพธ์ที่สร้างขึ้นจะถูกแยกไว้ใน /sandbox ประการที่สาม นโยบายเครือข่ายจะดำเนินการภายใต้หลักการ "ปฏิเสธโดยค่าเริ่มต้น และอนุญาตเฉพาะสิ่งที่จำเป็น" ซึ่งสามารถทำ Hot Reload ได้ในขณะที่ระบบกำลังทำงาน

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

ผู้เขียน・ผู้ตรวจสอบ

Yusuke Ishihara

Yusuke Ishihara

เริ่มเขียนโปรแกรมตั้งแต่อายุ 13 ปี ด้วย MSX หลังจบการศึกษาจากมหาวิทยาลัย Musashi ได้ทำงานพัฒนาระบบขนาดใหญ่ รวมถึงระบบหลักของสายการบิน และโครงสร้าง Windows Server Hosting/VPS แห่งแรกของญี่ปุ่น ร่วมก่อตั้ง Site Engine Inc. ในปี 2008 ก่อตั้ง Unimon Inc. ในปี 2010 และ Enison Inc. ในปี 2025 นำทีมพัฒนาระบบธุรกิจ การประมวลผลภาษาธรรมชาติ และแพลตฟอร์ม ปัจจุบันมุ่งเน้นการพัฒนาผลิตภัณฑ์และการส่งเสริม AI/DX โดยใช้ generative AI และ Large Language Models (LLM)

ติดต่อเรา

บทความแนะนำ