Octelium - ทางเลือกโอเพนซอร์สแทน Teleport, Cloudflare, Tailscale และ Ngrok

• Octelium เป็นแพลตฟอร์มโอเพนซอร์สแบบโฮสต์เองรุ่นใหม่ที่รองรับแบบรวมศูนย์ทั้ง Remote Access VPN, ZTNA, API/AI Gateway และอื่น ๆ
• ด้วยการ โฮสต์เองและสถาปัตยกรรมแบบ single-tenant จึงให้การเข้าถึงทรัพยากรภายในและสาธารณะทั้งหมดอย่างปลอดภัยบนพื้นฐานของ identity-based และ application layer (Layer 7)
• มีความสามารถที่ตอบโจทย์ความต้องการด้านความปลอดภัยสมัยใหม่ เช่น การเข้าถึงแบบ secret-less, การควบคุมตามนโยบายแบบละเอียด, การจัดการและการตรวจสอบแบบรวมศูนย์
• สามารถ มอบข้อได้เปรียบในการแข่งขันและใช้แทนได้ สำหรับโซลูชันเชิงพาณิชย์/โอเพนซอร์สหลากหลายแบบ เช่น Kubernetes, OpenVPN, Tailscale, Cloudflare Access และอื่น ๆ
• ใช้โมเดลโอเพนซอร์ส พร้อมวางฐานธุรกิจผ่าน ฟีเจอร์เชิงพาณิชย์และการให้สิทธิ์ใช้งาน โดยมุ่งเน้นการให้บริการแบบโฮสต์เองที่มีฟังก์ชันครบถ้วน

---

ความสำคัญและภาพรวมของโครงการ Octelium

• Octelium คือ แพลตฟอร์มการเข้าถึงแบบปลอดภัย Zero Trust สำหรับการโฮสต์เองรุ่นใหม่แบบรวมศูนย์และเป็นโอเพนซอร์ส ที่สามารถใช้แทนโซลูชันเชิงพาณิชย์อย่าง Teleport, Cloudflare, Tailscale และ Ngrok ได้
• เมื่อเทียบกับโซลูชันโอเพนซอร์ส/เชิงพาณิชย์เดิม จุดเด่นสำคัญคือ สามารถโฮสต์ทุกฟังก์ชันได้เองโดยไม่ลดทอนความสามารถ, ไม่มีค่าใช้จ่ายเพิ่มเติม และไม่ผูกติดกับผู้ขาย

Octelium คืออะไร

• Octelium เป็นแพลตฟอร์มจัดการการเข้าถึงแบบรวมศูนย์ที่ใช้แนวทาง identity-based และอัลกอริทึม Layer 7
• เป็นทางเลือกแทน Remote Access VPN (เช่น OpenVPN Access Server, Twingate, Tailscale) พร้อมรองรับบทบาทหลากหลาย เช่น ZTNA, BeyondCorp (เช่น Google BeyondCorp, Cloudflare Access, Teleport), ngrok (reverse proxy), API/AI Gateway, โครงสร้างพื้นฐาน PaaS แบบโฮสต์เอง, ตัวแทน Kubernetes Ingress และโครงสร้างพื้นฐาน Homelab
• รองรับทั้งวิธีแบบไคลเอนต์ที่อาศัย WireGuard/QUIC tunnel สำหรับการเข้าถึงของผู้ใช้ (ทั้งคนและ workload) และ การเข้าถึงผ่านเบราว์เซอร์แบบไม่ต้องใช้ไคลเอนต์ในสไตล์ BeyondCorp
• แกนหลักคือ policy-as-code, ความปลอดภัยตามบริบทและตัวตนแบบละเอียด และการยืนยันตัวตน/กำหนดสิทธิ์แบบ secret-less

กรณีการใช้งานหลัก

• Modern Remote Access VPN: ทำงานบน WireGuard/QUIC พร้อม ความปลอดภัยแบบไดนามิก, รับรู้ตัวตน, และระดับ application layer
• การจัดโครงสร้างการเข้าถึงแบบ ZTNA/BeyondCorp แบบรวมศูนย์
• secure tunnel/reverse proxy แบบโฮสต์เอง (ใช้แทน ngrok, Cloudflare Tunnel)
• PaaS แบบโฮสต์เอง (ดีพลอยและสเกล container app พร้อม public hosting แบบไม่ระบุตัวตน)
• API Gateway (ใช้แทน Kong Gateway, Apigee)
• AI Gateway (เชื่อมต่อ LLM provider และควบคุมตามตัวตน)
• การเข้าถึง SaaS API แบบรวมศูนย์และ secret-less
• ให้โครงสร้างพื้นฐานเกตเวย์สำหรับ MCP/A2A (มาตรฐาน model context และการสื่อสารระหว่างเอเจนต์)
• ตัวแทนขั้นสูงสำหรับ Kubernetes Ingress/Load Balancer
• Homelab (การจัดการระยะไกลอย่างปลอดภัยแบบรวมศูนย์สำหรับทรัพยากรส่วนตัว, IoT, คลาวด์ ฯลฯ)

คุณสมบัติหลัก

สถาปัตยกรรมแบบรวมศูนย์สมัยใหม่

• รองรับทรัพยากรทุกประเภท (ภายใน/หลัง NAT, สาธารณะ) และผู้ใช้ทุกแบบ (คน/workload) ด้วย การควบคุมแบบรับรู้ตัวตนในระดับ application layer
• มีให้ทั้งการเข้าถึงระยะไกลแบบ VPN และการเข้าถึงแบบไม่ใช้ไคลเอนต์สไตล์ BeyondCorp
• ทำงานบน Kubernetes พร้อมความสามารถในการสเกลแนวนอนและความพร้อมใช้งานสูงในตัว

การเข้าถึงแบบ dynamic secret-less

• รองรับการเข้าถึงแอป/ฐานข้อมูลจำนวนมากอย่างปลอดภัย เช่น HTTP/gRPC API, เว็บแอป, SSH, Kubernetes, PostgreSQL/MySQL โดย ไม่ต้องจัดการหรือแชร์ secret key
• แม้แต่ mTLS ก็เข้าถึงได้โดยไม่ต้องแชร์ PKI/ใบรับรอง

การควบคุมการเข้าถึงแบบรับรู้บริบท, อิงตัวตน และระดับ Layer 7

• มี ระบบนโยบาย (ABAC) แบบรวมศูนย์, เป็นโมดูล, และประกอบต่อกันได้ในตัว
• รองรับ ภาษานโยบาย อย่าง CEL, OPA และควบคุมได้ละเอียดในระดับทุกคำขอ

การกำหนดเส้นทาง/การตั้งค่าแบบไดนามิก

• สามารถทำ conditional routing ไปยังทรัพยากรเดียวกันได้ตามบริบทระดับบน บัญชี และเงื่อนไขที่แตกต่างกัน โดยอิงนโยบาย

การยืนยันตัวตนที่แข็งแกร่งอย่างต่อเนื่อง

• เชื่อมต่อกับ IdP มาตรฐานอย่าง OpenID Connect, SAML2.0
• workload ใช้ OIDC token เพื่อยืนยันตัวตนแบบไม่ใช้ความลับ
• รองรับระดับการยืนยันตัวตนของ NIST, MFA และการป้องกันฟิชชิง (เช่น Passkey, Yubikey)

การมองเห็นเชิงลึกและการตรวจสอบในระดับ application layer

• ผสานรวม OpenTelemetry บันทึกทุกคำขอแบบเรียลไทม์ และส่งไปยัง OTLP collector ภายนอกได้

Serverless SSH และการดีพลอย container app

• เข้าถึง container, IoT และโฮสต์ที่ไม่ใช่ SSH ได้ผ่าน SSH โดยไม่ต้องมีสิทธิ์ root
• รองรับการดีพลอย สเกล และเข้าถึงอย่างปลอดภัยสำหรับ container app ในลักษณะคล้าย PaaS

การจัดการแบบรวมศูนย์เชิงประกาศและเขียนเป็นโค้ดได้

• จัดการแบบ declarative เหมือน Kubernetes และสามารถทำให้สถานะคลัสเตอร์กลับมาเหมือนเดิมได้ด้วยคำสั่งเดียวหรือโค้ด
• ใช้งานผ่าน octeliumctl CLI และ gRPC API เพื่อการปฏิบัติการที่ เป็นมิตรกับ DevOps/GitOps

ไม่ต้องเปลี่ยนเครือข่ายและแก้ปัญหาเรื้อรังของ VPN

• ทรัพยากร upstream ไม่จำเป็นต้องรู้ถึงการมีอยู่ของ Octelium และสามารถให้บริการอย่างปลอดภัยหลัง NAT ได้โดยไม่ต้องเปิดพอร์ต
• ตั้งค่า unique dual-stack private IP และ private DNS ได้อัตโนมัติ

โอเพนซอร์สเต็มรูปแบบ, โฮสต์เองได้, ไม่ผูกกับผู้ขาย

• เปิดเผยซอร์สทั้งหมด ไม่มีการจำกัดฟีเจอร์ในเวอร์ชันเชิงพาณิชย์ และไม่มี Vendor Lock-in
• รองรับการจัดวางระบบที่สเกลได้ตั้งแต่ mini cluster แบบ single-node ไปจนถึงคลาวด์ขนาดใหญ่

ใบอนุญาตและการสนับสนุน

• ซอร์สของไคลเอนต์ใช้ Apache 2.0 และคลัสเตอร์ใช้ AGPLv3
• มี commercial license และการสนับสนุนระดับ enterprise โดยขณะนี้ยังจำกัดการมีส่วนร่วมจากภายนอก
• มีการสนับสนุนจากชุมชนผ่านเอกสารทางการ, Discord, Slack, อีเมล, Reddit ฯลฯ

สรุปหัวข้อสำคัญจากคำถามที่พบบ่อย

• ปัจจุบันอยู่ในช่วง Public Beta และเปิดเป็นโอเพนซอร์สหลังพัฒนาภายในมาเป็นเวลานาน
• พัฒนาโดยนักพัฒนาคนเดียว (George Badawi) และดำเนินงานด้วยตนเองโดยไม่มี VC หรือเงินทุนภายนอก
• สามารถทำหน้าที่เป็น VPN ได้ แต่ โดยพื้นฐานมุ่งไปที่ ZTA ที่ใช้พร็อกซีแบบรับรู้ตัวตน
• ไม่มีข้อจำกัดหรือการบังคับใช้เชิงพาณิชย์ที่ทำให้รู้สึกว่า "ไม่เหมือนโอเพนซอร์สจริง" และการโฮสต์เองพร้อมฟังก์ชันครบถ้วนคือเป้าหมายการออกแบบ
• โมเดลธุรกิจต่อยอดจาก การสนับสนุนทางเทคนิค, commercial license และฟีเจอร์เสริมระดับ enterprise (เช่น SIEM integration, Vault backend, EDR)

[GN⁺]

ความเห็นจาก Hacker News

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

  • ถึง TailScale จะน่าพอใจ แต่ก็รู้สึกว่าจำเป็นต้องมีคู่แข่ง ตอนนี้มีแนวโน้มว่าจะ IPO และถ้าไปถึงจุดนั้นโดยไม่มีคู่แข่ง ผมคิดว่ามีโอกาสสูงที่ราคาจะพุ่งแรง

  • สรุปได้ว่าเป็น programmable network tunnel fabric

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

  • เป็นฟีดแบ็กที่ดีมาก ผมเข้าใจว่าคำวิจารณ์นี้สมเหตุสมผล เพราะ Octelium ถูกออกแบบมาโดยตั้งใจให้ทำงานได้หลายอย่างพร้อมกัน Octelium คือแพลตฟอร์ม zero-trust access แบบรวมศูนย์/อเนกประสงค์ ที่ใช้ได้กับหลายกรณีระหว่างมนุษย์กับ workload และระหว่าง workload กับ workload (ในเอกสารมีตัวอย่างหลายแบบอย่างละเอียด) เพราะแบบนี้คนใช้ใหม่จึงอาจสับสนได้ สาเหตุที่ first commit โผล่มาแบบกะทันหันก็เพราะจริงๆ แล้วผมพัฒนามาตั้งแต่ต้นปี 2020 แต่พอตัดสินใจเปิดซอร์สก็เริ่มรีโพสาธารณะใหม่แบบสะอาดโดยไม่มี commit แรกๆ เพื่อหลีกเลี่ยงความเสี่ยงข้อมูลส่วนตัวรั่วไหล ตลอด 5 ปีที่ผ่านมา ผมทำ manual commit ไปเกือบ 9,000 ครั้ง ช่วงแรกมันเป็นแค่ WireGuard VPN สำหรับ remote access แบบง่ายๆ แต่หลังจากนั้นก็เปลี่ยนไปอย่างสิ้นเชิงจนกลายเป็นสถาปัตยกรรม ฟีเจอร์ และความซับซ้อนแบบปัจจุบัน

  • ควรใจกว้างกับนักพัฒนาโอเพนซอร์สหน่อย ไม่มีใครรู้ภูมิหลังหรือแรงจูงใจของ OP และอาจเป็นแค่คนที่ทำเพราะสนุกก็ได้ ไม่จำเป็นต้องหาเหตุผลมารองรับ นี่คือโอเพนซอร์สและฟรีซอฟต์แวร์ ส่วนคำวิจารณ์ที่ว่าผู้ใช้ไม่สามารถอธิบายมันในประโยคเดียวได้นั้น จริงๆ ก็อธิบายได้ค่อนข้างง่ายเหมือน tailscale, cloudflare access, ngrok ถ้าคุณไม่ได้ต้องการผลิตภัณฑ์ประเภทนั้นตั้งแต่แรก ผลิตภัณฑ์นี้ก็คงไม่จำเป็นสำหรับคุณเช่นกัน

• ผมเพิ่งลองดู Octelium ไม่นานนี้ และดูเหมือนว่าต้องมี Kubernetes cluster ตอนติดตั้ง ถ้าเป็นจริงก็ถือว่า barrier to entry สูงเกินไป เราอยากแค่เอาโหนดมาเข้ากับ overlay network ไม่ได้อยากเพิ่ม dependency ของ infrastructure อื่นอย่าง k8s เข้าไปด้วย ด้วยความที่ควรพึ่งพา internal service ให้น้อยที่สุดหรือไม่มีเลย การเลือกแบบนี้จึงทำให้งง ถ้า SDN จำเป็นต้องอยู่บนคลัสเตอร์ แบบนั้นอาจเป็นกลุ่มเป้าหมายก็ได้ แต่ก็สงสัยว่ามีแค่นั้นหรือไม่ หวังว่า integration กับ k8s จะเป็นทางเลือก ไม่ใช่ข้อบังคับหรือวิธี deploy แบบเดียว ถ้าใครมีข้อมูลเกี่ยวกับการใช้ Octelium โดยไม่ใช้ k8s รบกวนบอกหน่อย

  • Octelium เป็น distributed system ที่ทำงานได้บนหนึ่งหรือหลายโหนด ตอนนี้จำเป็นต้องรันบน Kubernetes แต่ภายในไม่ได้ผูกกับ k8s อย่างแน่นหนา ดังนั้นการพอร์ตไปยัง orchestrator อื่นอย่าง Nomad จึงทำได้ไม่ยาก เหตุผลที่ใช้ k8s เป็น infrastructure ของตัวเองก็เพื่อช่วยลดงาน manual ที่ผู้ดูแลระบบต้องทำเวลาจัดการสถาปัตยกรรม zero-trust เช่น deploy proxy, scale, teardown เป็นต้น Octelium มีทั้ง control plane และ data plane ดังนั้นแค่ octeliumctl apply ระบบก็จะ deploy, manage, scale และ teardown ทุก service ให้อัตโนมัติ ไม่ต้องทำงานมืออย่างเปิดพอร์ต firewall หรืออย่างอื่น Kubernetes จัดการคอนเทนเนอร์อย่างไร Octelium ก็ทำหน้าที่ orchestration ให้กับ service, proxy และองค์ประกอบอื่นในแบบเดียวกัน ไม่ต้องจัดการเรื่องซับซ้อนอย่างจำนวนโหนดหรือ CRI networking ด้วย คลัสเตอร์จะครอบคลุมทุกโหนดและจัดการได้แบบ declarative/programmable ระหว่างใช้งาน Octelium ไม่จำเป็นต้องเข้าใจ Kubernetes ลึกๆ เลย นอกจากงานบางอย่างอย่างการ scale ตัวคลัสเตอร์ k8s เอง หรือการตั้งค่า TLS certificate ของ k8s ก็สามารถโฟกัสที่ Octelium ได้อย่างเดียว หากอยากทราบรายละเอียดเพิ่มเติม แนะนำให้อ่าน เอกสารทางการ

• การโปรย buzzword เยอะเกินไปทำให้ไม่ไว้ใจทันที แม้ดูหน้า GitHub ก็ยังไม่ค่อยเข้าใจว่าผลิตภัณฑ์นี้ทำอะไรแบบเป็นรูปธรรม

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

• โดยรวมแล้วมีผลิตภัณฑ์คล้ายกันอยู่เยอะมากแล้ว เช่น Tinc, Hamachi, ZeroTier, Nebula, Tailscale, Netbird ฯลฯ แต่ละตัวมีข้อดีข้อเสียของตัวเอง แต่ในทางปฏิบัติผมคิดว่าความแตกต่างที่ชัดจริงๆ มีไม่มาก ฟีเจอร์ที่ผมอยากได้จริงๆ คือ zero-trust "lighthouse" โดย Zerotier กับ Tailscale มีสิทธิ์เพิ่มโหนดเข้าไปในบัญชี/เครือข่ายของผมได้ สิ่งที่ผมต้องการคือ self-hosting แบบสมบูรณ์ และให้ lighthouse ไม่เป็นส่วนหนึ่งของเครือข่าย แต่ทำหน้าที่แค่คอยเฝ้าดูโหนดเท่านั้น คงต้องไปหาข้อมูลเพิ่มเกี่ยวกับเรื่องนี้

  • พออ่านเอกสารแล้ว รู้สึกว่าหลายคนกำลังมองข้ามคุณค่าที่แท้จริงของ Octelium ถ้ามันทำงานได้ตามที่เอกสารบอกจริง นี่อาจเป็นเพชรที่ยังไม่มีใครค้นพบ สิ่งที่องค์กรต้องการคือการก้าวพ้น security แบบ boundary-based เดิมๆ ไปสู่แนวคิดที่ Google überProxy/BeyondCorp นำเสนอ (และตอนนี้ถูกทำให้เจือจางด้วย buzzword ต่างๆ) กล่าวคือ การแยก production system, ภายในองค์กร และอินเทอร์เน็ตภายนอกออกจากกันอย่างชัดเจน พร้อม UX ที่โปร่งใสต่อพนักงานมากที่สุด การจัดการสิทธิ์ของทราฟฟิกที่ไหลข้ามขอบเขตอย่างชัดเจน และการยืนยันตัวตนที่เข้มแข็งของ client ทุกตัว นอก Google สภาพแวดล้อมที่มีโปรโตคอลหลากหลายทำให้มีข้อจำกัดอยู่มาก proxy ที่รับรู้โปรโตคอล แม้เดิมจะทำได้เพียงการตัดสินใจและ logging แบบ coarse-grain แต่ถ้ารองรับการอนุมานชนิดข้อมูลด้วย ก็จะควบคุมสิทธิ์ได้ละเอียดในระดับ request มากขึ้นมาก (คือเงื่อนไขของทุก request ถูกเปิดให้ policy engine มองเห็น) เอกสารอาจยืดยาวและการตลาดอาจยังไม่ลื่นไหล แต่ปัญหานี้ซับซ้อนมากจนยังไม่มีใครแก้ได้สมบูรณ์ Teleport เป็นรายแรกๆ ที่ลุยทั้ง OSS และเชิงพาณิชย์ StrongDM ก็ทำอะไรที่น่าสนใจ และผมก็หวังว่า Hashicorp จะลงทุนกับด้านนี้มากขึ้นด้วย (*เป็นความเห็นส่วนตัว)

  • Octelium อาจใช้แทนผลิตภัณฑ์ที่พูดถึงข้างต้นได้ แต่ทิศทางและวิธีใช้งานของมันกว้างกว่า และชัดเจนว่าเน้น zero-trust มากกว่า มันเป็นมากกว่าเครื่องมือ VPN/remote access ทั่วไป อยากให้ลองอ่านเอกสารเพื่อเข้าใจเจตนา สถาปัตยกรรม และฟีเจอร์ของมันจริงๆ ทุกวันนี้ทุกผลิตภัณฑ์โฆษณาว่าเป็น "zero-trust" แต่สิ่งที่เป็น ZTA ตามนิยามของ NIST จริงๆ (เช่น L7-aware proxy, policy decision point, การควบคุมสิทธิ์แบบละเอียดราย request ที่อิง policy-as-code, identity แบบรวมศูนย์, การรวมข้อมูลจากเครื่องมือ SIEM/SSO/Threat intelligence ภายนอก ฯลฯ) มีอยู่ไม่กี่ราย ผลิตภัณฑ์เชิงพาณิชย์ที่จัดเป็น "zero-trust" แบบจริงๆ มีอย่าง Cloudflare Access, Teleport, Google BeyondCorp, StrongDM, Zscaler เป็นต้น กลับกัน หลายบริษัทใช้คำนี้พร่ำเพรื่อจนทำให้ความหมายของ "zero-trust ที่แท้จริง" เจือจางลงไปมาก

  • ลองดู cathedral mode ของ sanctum ได้ self-hosting ได้เต็มรูปแบบ และโหนดทำหน้าที่แค่ discovery เท่านั้น พอตั้ง tunnel ได้แล้ว โหนด cathedral จะไม่เข้ามาเกี่ยวข้องอีก ยกเว้นตอนกระจาย black key หรือเมื่อ peer อยู่หลัง NAT เท่านั้น ยังมี reliquary ด้วย ผมใช้อยู่เอง sanctum, reliquary

  • รายการโปรเจกต์ที่เกี่ยวข้องเพิ่มเติมดูได้ที่ awesome-tunneling

• เข้าใจว่าการใส่คีย์เวิร์ด "AI" เป็นเรื่องของ SEO คล้ายกับการใส่คำว่า "Reddit" ในพาดหัวข่าว ถึงเนื้อหาจะดี วิธีนี้ก็ไม่ค่อยสร้างความประทับใจที่ดี แผนภาพ API gateway กับ AI gateway ก็ดูแทบจะเหมือนกัน tailscale blog: AI-normal

  • API gateway กับ AI gateway มีฟังก์ชันร่วมกันหลายอย่าง ตัวอย่างควรดูจากเอกสารโดยตรง ตัวอย่าง AI Gateway, ตัวอย่าง API Gateway กำลังทำงานขยายความสามารถด้านการแก้ไข HTTP request/body อยู่ด้วย โดยจะมี ext_proc ของ envoy เข้ามาเร็วๆ นี้ และอาจเพิ่มการรองรับ proxy-wasm ตามความต้องการ ดูคำอธิบายเกี่ยวกับ HTTP ได้ที่ คำอธิบายเกี่ยวกับ HTTP

• กำลังมองหาโอเพนซอร์สทางเลือกของ Tailscale อย่างจริงจัง แต่ README ยาวเกินไป อยากให้ย่อให้เหลือแค่ภาพรวมโปรเจกต์กับลิงก์เอกสารแบบกระชับ

  • headscale คือทางเลือกโอเพนซอร์สของ tailscale headscale GitHub

• จุดแข็งที่สุดของ Tailscale คือการเชื่อมต่อ P2P ที่ง่าย ส่วน Octelium ดูเหมือนจะใช้โครงสร้าง router แบบรวมศูนย์มากกว่า เลยอยากรู้ว่าเข้าใจถูกไหม

  • Octelium ไม่ใช่ P2P VPN แต่เป็นสถาปัตยกรรม zero-trust แน่นอนว่ามันทำหน้าที่เป็น VPN สำหรับ remote access ที่ใช้ WireGuard/QUIC ได้ด้วย แต่ในเชิงโครงสร้างมันใกล้กับ Cloudflare Access และ Teleport มากกว่า ไม่ว่าจะเป็นการควบคุมสิทธิ์การเข้าถึงระดับ L7, การเข้าถึงแบบไร้ซีเคร็ต (ฉีดพวกคีย์/โทเคน/API key ให้โดยไม่ต้องแจกจ่ายตรงๆ), การตั้งค่าและ routing แบบยืดหยุ่น, การมองเห็นและการตรวจสอบแบบเรียลไทม์ผ่าน OpenTelemetry เป็นต้น ทั้งหมดนี้ต่างจาก P2P VPN โดยพื้นฐาน สถาปัตยกรรม ZTNA/BeyondCorp แบบจริงจัง (ยกเว้น service mesh) มีข้อจำกัดพื้นฐานถ้าจะทำในรูปแบบ P2P VPN เพราะหากต้องการควบคุมสิทธิ์ราย request และมี visibility ที่เพียงพอ ก็จำเป็นต้องมี L7-aware proxy เสมอ

  • เพื่ออ้างอิง Tailscale เองก็มีกรณีที่แพ็กเก็ตวิ่งผ่าน router แบบรวมศูนย์เช่นกัน คำอธิบายเรื่อง connection types ของ Tailscale

• ผมไม่เข้าใจว่าทำไมการติดตั้ง k3s cluster ต้องฝังมาในแอปด้วย ดูเหมือนว่าการเพิ่มเข้าไปใน infrastructure เดิมได้ง่ายๆ หรือมี CRD แบบเรียบง่ายสำหรับ expose service จะชัดเจนกว่า แนวคิดแบบโอเพนซอร์ส Cloudflare Access/Teleport นั้นเจ๋งมาก แต่ส่วนใหญ่สุดท้ายก็กลายเป็นการคัสตอมบน k8s อยู่ดี ถ้าโฟกัสที่ฟังก์ชันด้าน access โดยตรงมากกว่านี้ ผมน่าจะสนใจกว่า

  • Octelium cluster เป็น distributed system ที่ทำงานอยู่บน k8s ติดตั้งได้ทั้งบน k8s/k3s แบบโหนดเดียว และบน k8s สำหรับงาน "production" แบบหลายโหนด Octelium ไม่ใช่แค่ wrapper ของ k8s แต่ใช้ k8s เป็น infrastructure แล้วสร้างแพลตฟอร์มของตัวเองขึ้นมา แต่ละโหนดทำหน้าที่เป็น gateway/host สำหรับ Octelium Service และแต่ละ Service จะถูก deploy เป็น k8s service ที่มี proxy รับรู้ตัวตน ทำงานเป็น endpoint ของ tunnel แบบ WireGuard/QUIC และมี private dual-stack IP แบบคงที่ตามการ scale โครงสร้างนี้เหมือนการจัดการ identity-aware proxy แบบเดียวกับคอนเทนเนอร์ ต่างจาก ZTA เดิมๆ (เช่น Teleport, Pomerium ฯลฯ) ที่ผู้ดูแลต้องคอยเปิด/ปิดแต่ละ proxy เอง ใน Octelium แค่สร้างหรือลบ resource แบบ declarative ผ่าน octeliumctl apply หรือ gRPC API แล้วก็ลืมเรื่องการจัดการที่เหลือไปได้เลย จริงๆ เคยใช้ CRD มาก่อน แต่เพราะมี resource เยอะมาก เช่น user, session, service, namespace (ซึ่งบางส่วนแยกจาก k8s namespace), policy, device, credential ฯลฯ และปริมาณข้อมูลก็มาก ทำให้ backend แบบ etcd ไม่เสถียรพอ สุดท้ายจึงเพิ่ม backend ของ Postgres แยกต่างหาก

• มีโปรเจกต์คล้ายกันที่ออกมาแล้วเยอะมาก

• อยากรู้ว่ามันเป็นตัวแทนสำหรับระบบจัดการสิทธิ์เข้าถึงระดับองค์กรใหญ่ (corp botnet) หรือเปล่า ถ้าผมเป็นองค์กรใหญ่ ผมคงอยากได้ซอฟต์แวร์จากบริษัทยักษ์พร้อมแพ็กเกจซัพพอร์ตเพื่อความมั่นคง เลยไม่แน่ใจว่าโปรเจกต์โอเพนซอร์สจากนักพัฒนาเดี่ยวจะแก้ปัญหานี้ได้จริงไหม

  • Octelium ไม่ได้มีไว้แค่แทนของระบบใดระบบหนึ่ง แต่เป็นแพลตฟอร์มด้าน secure access แบบอเนกประสงค์ที่ใช้ได้ตั้งแต่ระบบเล็กไปจนถึง enterprise และรองรับทุกระดับทั้ง dev/startup/enterprise ยกตัวอย่างเช่น Kubernetes รองรับได้ทั้งเว็บไซต์คอนเทนเนอร์เดี่ยว, API gateway สำหรับไมโครเซอร์วิสไม่กี่ตัว, ไปจนถึง service mesh ขนาดใหญ่หลายร้อยหรือหลายพันโหนด Octelium ก็มีขอบเขตการใช้งานกว้างมากในลักษณะเดียวกัน