- Octelium là nền tảng tự host mã nguồn mở thế hệ mới, hỗ trợ tích hợp VPN truy cập từ xa, ZTNA, API/AI gateway và hơn thế nữa
- Với mô hình tự host và single-tenant, nền tảng cung cấp kết nối bảo mật dựa trên danh tính ở lớp ứng dụng (Layer 7) cho mọi tài nguyên nội bộ và công khai
- Bao gồm các tính năng đáp ứng yêu cầu bảo mật hiện đại như truy cập không cần secret (secret-less), kiểm soát chi tiết dựa trên chính sách, quản trị tập trung và kiểm toán
- Có thể mang lại lợi thế cạnh tranh và thay thế nhiều giải pháp thương mại/mã nguồn mở hiện có như Kubernetes, OpenVPN, Tailscale, Cloudflare Access
- Áp dụng mô hình mã nguồn mở, đồng thời xây dựng nền tảng kinh doanh qua hỗ trợ tính năng thương mại và cấp phép, với trọng tâm là cung cấp môi trường tự host đầy đủ tính năng
Tầm quan trọng và tổng quan về dự án Octelium
- Octelium là nền tảng truy cập bảo mật Zero Trust tích hợp, tự host, mã nguồn mở thế hệ mới, có thể thay thế các giải pháp thương mại như Teleport, Cloudflare, Tailscale và Ngrok.
- So với các giải pháp mã nguồn mở/thương mại hiện có, ưu điểm lớn là có thể tự host toàn bộ tính năng mà không bị cắt giảm, đồng thời tránh được chi phí bổ sung và phụ thuộc nhà cung cấp.
Octelium là gì
- Octelium là nền tảng quản lý truy cập hợp nhất áp dụng thuật toán dựa trên danh tính và Layer 7
- Đây là lựa chọn thay thế cho VPN truy cập từ xa (OpenVPN Access Server, Twingate, Tailscale, v.v.), đồng thời đáp ứng nhiều vai trò như ZTNA, BeyondCorp (Google BeyondCorp, Cloudflare Access, Teleport, v.v.), ngrok (reverse proxy), API/AI gateway, hạ tầng PaaS tự xây, thay thế Kubernetes ingress, và hạ tầng homelab
- Hỗ trợ cả mô hình client dựa trên đường hầm WireGuard/QUIC cho truy cập của người dùng (con người và workload) / tổ chức / ứng dụng, lẫn truy cập qua trình duyệt không cần client theo kiểu BeyondCorp
- Trọng tâm là policy-as-code, cùng với bảo mật dựa trên ngữ cảnh và danh tính ở mức chi tiết, cũng như xác thực và phân quyền không cần secret
Các trường hợp sử dụng chính
- VPN truy cập từ xa hiện đại: dựa trên WireGuard/QUIC, động, nhận biết danh tính, bảo mật ở lớp ứng dụng
- Xây dựng truy cập ZTNA/BeyondCorp hợp nhất
- Đường hầm bảo mật/reverse proxy tự host (thay thế ngrok, Cloudflare Tunnel)
- PaaS tự host (triển khai/mở rộng ứng dụng container, hosting công khai ẩn danh)
- API gateway (thay thế Kong Gateway, Apigee)
- AI gateway (kết nối nhà cung cấp LLM, kiểm soát dựa trên danh tính)
- Truy cập API SaaS hợp nhất không cần secret
- Cung cấp hạ tầng gateway MCP/A2A (chuẩn model context và giao tiếp giữa các agent)
- Thay thế nâng cao cho Kubernetes ingress/load balancer
- Homelab (quản trị từ xa an toàn, hợp nhất cho tài nguyên cá nhân, IoT, cloud, v.v.)
Các tính năng chính
Kiến trúc hợp nhất hiện đại
- Hỗ trợ kiểm soát theo đơn vị lớp ứng dụng, nhận biết danh tính cho mọi tài nguyên (nội bộ/sau NAT, công khai) và mọi người dùng (con người/workload)
- Cung cấp cả truy cập từ xa dựa trên VPN và truy cập không cần client theo kiểu BeyondCorp
- Chạy trên Kubernetes, tích hợp sẵn khả năng mở rộng ngang và tính sẵn sàng cao
Truy cập động không cần secret (secret-less)
- Hỗ trợ truy cập an toàn tới nhiều ứng dụng/CSDL như HTTP/gRPC API, web app, SSH, Kubernetes, PostgreSQL/MySQL mà không cần quản lý hay chia sẻ khóa bí mật
- Ngay cả mTLS cũng có thể truy cập mà không cần chia sẻ PKI/chứng chỉ
Kiểm soát truy cập theo ngữ cảnh, danh tính và Layer 7
- Tích hợp sẵn hệ thống chính sách (ABAC) theo mô-đun, có thể kết hợp linh hoạt và quản lý tập trung
- Hỗ trợ ngôn ngữ chính sách như CEL, OPA, cho phép kiểm soát chi tiết trên từng request
Định tuyến/cấu hình động
- Có thể định tuyến có điều kiện, theo tài khoản và ngữ cảnh cấp cao khác nhau tới cùng một tài nguyên dựa trên chính sách
Xác thực mạnh liên tục
- Tích hợp với các IdP chuẩn như OpenID Connect, SAML2.0
- Workload có thể xác thực không cần secret bằng token OIDC
- Hỗ trợ mức đảm bảo xác thực theo NIST, MFA và chống phishing (Passkey, Yubikey, v.v.)
Khả năng quan sát sâu và kiểm toán ở lớp ứng dụng
- Tích hợp OpenTelemetry, ghi log thời gian thực cho mọi request và gửi tới OTLP collector bên ngoài
SSH serverless và triển khai ứng dụng container
- Có thể SSH vào container, thiết bị IoT và host không có SSH mà không cần quyền root
- Hỗ trợ triển khai, mở rộng và truy cập bảo mật cho ứng dụng container tương tự PaaS
Quản trị tập trung, khai báo và có thể lập trình
- Quản lý theo kiểu khai báo giống Kubernetes, có thể tái tạo trạng thái cluster bằng một lệnh hoặc bằng code
- Vận hành thân thiện với DevOps/GitOps qua CLI
octeliumctl và gRPC API
Không cần thay đổi mạng và khắc phục các vấn đề cố hữu của VPN
- Tài nguyên upstream không cần biết đến sự tồn tại của Octelium, và vẫn có thể vận hành dịch vụ an toàn sau NAT mà không cần mở cổng
- Tự động hóa cấu hình như private IP dual-stack riêng, private DNS, v.v.
Mã nguồn mở hoàn toàn, tự host, không bị khóa nhà cung cấp
- Toàn bộ mã nguồn được công khai, không có giới hạn tính năng ở bản thương mại hay vendor lock-in
- Hỗ trợ cấu hình mở rộng từ mini cluster một node tới môi trường cloud quy mô lớn
Giấy phép và hỗ trợ
- Mã nguồn phía client dùng Apache 2.0, cluster dùng AGPLv3
- Có giấy phép thương mại và hỗ trợ enterprise, hiện việc đóng góp từ bên ngoài còn bị giới hạn
- Hỗ trợ cộng đồng qua tài liệu chính thức, Discord, Slack, email, Reddit, v.v.
Tóm tắt các mục chính trong phần câu hỏi thường gặp
- Hiện đang ở giai đoạn Public Beta, sau thời gian dài phát triển nội bộ mới chuyển sang mã nguồn mở
- Dự án do một nhà phát triển duy nhất (George Badawi) dẫn dắt, đang tự vận hành mà không có VC hay vốn bên ngoài
- Có thể đóng vai trò VPN, nhưng về bản chất hướng tới ZTA dựa trên proxy nhận biết danh tính
- Không có các ràng buộc kiểu “không giống mã nguồn mở thực sự” hay ép buộc dùng bản thương mại; mục tiêu thiết kế là tự host và cung cấp đầy đủ tính năng
- Mô hình kinh doanh phát sinh từ hỗ trợ kỹ thuật, giấy phép thương mại và các tính năng bổ sung cho enterprise (ví dụ: tích hợp SIEM, Vault backend, EDR)
1 bình luận
Ý kiến trên Hacker News
Với những ai khó hiểu Octelium làm gì, tôi chia sẻ chỗ có phần giải thích rõ ràng nhất mà tôi tìm được: liên kết Cách Octelium hoạt động - tài liệu chính thức là dễ hiểu nhất. Thay vì liệt kê mọi tính năng có thể có của Octelium để gây rối, cách tiếp cận bắt đầu từ khái niệm cốt lõi rồi giải thích dần dần rất cuốn hút. Các chức năng chính là một gateway kiểu VPN có thể hiểu các giao thức nâng cao và đưa ra quyết định bảo mật chi tiết dựa trên nội dung, cùng với một lớp cấu hình cluster được xây dựng trên Kubernetes. Hai phần này kết hợp lại thành một dạng "đám mây cá nhân". Nó cung cấp rất nhiều tính năng như các nền tảng cloud lớn, nhưng lại khó quyết định nên dùng cái nào trước. Đây là một hệ thống rất hay, có tiềm năng được dùng cho homelab cá nhân, các công ty nhỏ muốn tiết kiệm chi phí cloud, PaaS tùy biến, v.v.
TailScale khá ổn, nhưng tôi cảm thấy cần có đối thủ cạnh tranh. Công ty này có vẻ đang hướng tới IPO, và khi đã bước vào giai đoạn đó thì nếu không có đối thủ, giá rất có thể sẽ tăng mạnh.
Có thể tóm gọn nó là một programmable network tunnel fabric.
Theo quan điểm cá nhân, tôi muốn chia sẻ một vài vấn đề và lý do khiến người dùng khó tránh khỏi hoài nghi. Việc thiếu lịch sử phát triển, một commit đầu tiên khổng lồ không rõ nguồn gốc, thiếu thông tin công khai, trông không giống một công ty có thật, cộng thêm kiểu marketing tuyên bố giải quyết mọi thứ nhưng không có bằng chứng về bảo mật, tất cả đều làm giảm lòng tin. Trong tình huống như thế này, cần thêm thông tin để biết liệu đây có phải là công nghệ tự phát triển thực sự hay chỉ xây dựng trên các công nghệ sẵn có đủ đáng tin cậy. Nếu muốn phát hành như một sản phẩm kinh doanh thì phải tạo được độ tin cậy. Ngược lại, nếu đây là dự án cá nhân thì việc cố tỏ ra như một doanh nghiệp lại có thể trông như giả mạo/lừa đảo/tín hiệu cảnh báo. Thật khó để tích cực về việc một nhà phát triển đơn lẻ đột nhiên tung ra sản phẩm cạnh tranh với các công ty lớn. Điều quan trọng là phải nhấn mạnh rõ ràng tính bảo mật. Nếu mục đích của phần mềm còn khó giải thích chỉ trong một câu thì đó sẽ là một cuộc chiến vất vả. Việc liệt kê thêm nhiều tính năng không phải là lời giải. Ngược lại, nó còn tạo cảm giác kiểu "cứ cài tôi đi bằng mọi giá", khiến người ta chẳng muốn thử nữa. Tôi chỉ ra rằng điều này rất có thể sẽ cản trở thành công của dự án.
Đây là phản hồi rất tốt. Tôi hiểu sự chính đáng của lời phê bình này vì Octelium được thiết kế có chủ đích để đảm nhiệm nhiều chức năng cùng lúc. Octelium là một nền tảng truy cập zero-trust hợp nhất/tổng quát, có thể dùng cho nhiều trường hợp giữa người-với-workload và workload-với-workload (tài liệu có giải thích chi tiết nhiều ví dụ). Vì vậy, từ góc nhìn của người mới, việc thấy nó khó hiểu là điều dễ hiểu. Việc commit đầu tiên xuất hiện đột ngột là do tôi thực sự đã phát triển nó từ đầu năm 2020, nhưng khi quyết định công khai mã nguồn thì để tránh rủi ro lộ thông tin cá nhân, tôi bắt đầu bằng một kho lưu trữ công khai sạch, không có các commit ban đầu. Trong 5 năm qua tôi đã thực hiện gần 9.000 commit thủ công, và ban đầu nó chỉ là một VPN WireGuard truy cập từ xa đơn giản, sau đó đã thay đổi hoàn toàn thành kiến trúc, tính năng và độ phức tạp như hiện nay.
Cần rộng lượng hơn với các nhà phát triển mã nguồn mở. Không ai biết bối cảnh hay động cơ của OP, có thể đây chỉ là dự án làm cho vui. Họ không cần phải biện minh. Đây là phần mềm mã nguồn mở và miễn phí. Về chỉ trích rằng không thể mô tả sản phẩm trong một câu, thật ra nó có thể được giải thích khá đơn giản như tailscale, cloudflare access hay ngrok. Nếu bạn không cần những sản phẩm như thế, thì ngay từ đầu bạn cũng không cần sản phẩm này.
Tôi vừa xem qua Octelium gần đây, và có vẻ như khi cài đặt thì bắt buộc phải có cluster Kubernetes. Nếu đúng vậy thì rào cản gia nhập quá cao. Chúng tôi muốn gắn các node vào một overlay network, chứ không muốn phát sinh thêm phụ thuộc vào hạ tầng khác như k8s. Việc chọn hướng này khá khó hiểu, vì với các dịch vụ nội bộ thì phụ thuộc nên được giảm thiểu tối đa hoặc không có. Nếu SDN cần chạy trên cluster thì có thể đó chính là đối tượng mục tiêu, nhưng tôi thắc mắc liệu có chỉ vậy không. Tôi hy vọng tích hợp k8s là tùy chọn, chứ không phải điều kiện tiên quyết bắt buộc hay cách triển khai duy nhất. Nếu có tài liệu nào về việc dùng Octelium mà không cần k8s thì mong được chỉ giúp.
octeliumctl applylà mọi dịch vụ sẽ được tự động triển khai, quản lý, scale và gỡ bỏ. Không cần thao tác thủ công như mở cổng firewall. Giống như Kubernetes quản lý container, Octelium cũng tự động điều phối các service, proxy, v.v. tương tự như vậy. Cũng không cần xử lý các quản trị phức tạp như số lượng node hay CRI networking. Cluster bao quát toàn bộ node và có thể được quản lý theo cách khai báo/lập trình. Khi vận hành Octelium, hoàn toàn không cần hiểu sâu về Kubernetes; ngoại trừ một số việc cụ thể như scale cluster k8s hay cấu hình chứng chỉ TLS cho chính k8s, bạn chỉ cần làm việc với Octelium. Muốn biết thêm chi tiết, tôi khuyên nên xem tài liệu chính thức.Tôi lập tức thấy cực kỳ thiếu tin tưởng khi thấy quá nhiều buzzword bị tung ra. Ngay cả khi xem trang GitHub, tôi vẫn không hiểu rõ sản phẩm cụ thể làm gì.
Nhìn tổng thể thì đã có quá nhiều sản phẩm tương tự như Tinc, Hamachi, ZeroTier, Nebula, Tailscale, Netbird, v.v. Mỗi cái đều có ưu nhược điểm riêng, nhưng tôi nghĩ trên thực tế khác biệt lớn là rất ít. Tính năng mà cá nhân tôi thực sự muốn là một zero-trust "lighthouse". Zerotier và Tailscale có quyền thêm node vào tài khoản/mạng của tôi. Điều tôi muốn là tự host hoàn toàn, và lighthouse không phải là một phần của mạng mà chỉ đóng vai trò giám sát node. Tôi sẽ phải tìm hiểu thêm về chuyện này.
Đọc tài liệu xong, tôi thấy nhiều người đang bỏ lỡ giá trị thực sự của Octelium. Nếu nó thực sự hoạt động đúng như những gì tài liệu mô tả, thì đây có thể là một viên ngọc chưa được phát hiện. Điều doanh nghiệp mong muốn là thoát khỏi mô hình bảo mật theo ranh giới truyền thống để tiến tới khái niệm mà Google überProxy/BeyondCorp đưa ra (và đã bị làm loãng bởi vô số buzzword), tức là tách bạch rõ ràng giữa hệ thống sản xuất, nội bộ doanh nghiệp và Internet bên ngoài, đồng thời mang lại UX minh bạch tối đa cho nhân viên nội bộ, quản lý quyền đối với lưu lượng đi qua các ranh giới một cách rõ ràng, và xác thực danh tính mạnh mẽ cho mọi client. Bên ngoài Google thì còn nhiều ràng buộc do môi trường giao thức rất đa dạng. Proxy nhận biết giao thức, khi chỉ dừng ở mức đưa ra quyết định và ghi log coarse-grain, thì còn hạn chế; nhưng khi hỗ trợ cả suy luận kiểu dữ liệu, việc kiểm soát quyền ở cấp từng request có thể tinh vi hơn nhiều (mọi điều kiện của từng request đều được phơi bày cho policy engine). Tài liệu thì dài dòng và phần marketing chưa mượt, nhưng bản thân bài toán này quá phức tạp nên chưa ai giải quyết trọn vẹn được. Teleport là bên đi đầu cả ở OSS lẫn thương mại hóa, StrongDM cũng có những thử nghiệm thú vị. Tôi cũng mong Hashicorp đầu tư thêm vào mảng này (*ý kiến cá nhân).
Octelium có thể thay thế các sản phẩm được nhắc ở trên, nhưng mục tiêu và cách sử dụng của nó rộng hơn và rõ ràng thiên về zero-trust hơn. Nó không chỉ là một công cụ VPN/truy cập từ xa đơn thuần. Mong mọi người thật sự đọc tài liệu để hiểu ý đồ, kiến trúc và tính năng của nó. Ngày nay sản phẩm nào cũng quảng cáo là "zero-trust", nhưng thực tế số ít mới là ZTA đúng nghĩa theo định nghĩa của NIST (tức proxy nhận biết L7, policy decision point, kiểm soát truy cập chi tiết theo từng request dựa trên policy-as-code, danh tính tập trung, tích hợp thông tin từ công cụ SIEM/SSO/Threat intelligence bên ngoài, v.v.). Trên thực tế, các sản phẩm thương mại được xem là ZTA "thật sự" gồm Cloudflare Access, Teleport, Google BeyondCorp, StrongDM, Zscaler, v.v. Trái lại, xu hướng hiện nay là các công ty lạm dụng thuật ngữ này đến mức làm loãng khái niệm "zero-trust thật sự".
Hãy tham khảo chế độ cathedral của sanctum. Nó có thể tự host hoàn toàn, và các node chỉ đóng vai trò discovery. Khi tunnel đã được thiết lập thì node cathedral không còn tham gia nữa, ngoại trừ việc phân phối black key hoặc khi peer nằm sau NAT. Cũng có reliquary. Tôi đang trực tiếp vận hành cả hai. sanctum, reliquary
Có thể xem thêm danh sách các dự án liên quan tại awesome-tunneling
Tôi hiểu việc chèn từ khóa "AI" là vì mục đích SEO. Nó giống như gắn chữ "Reddit" vào tiêu đề bài báo vậy. Dù nội dung có hay đến đâu thì cách làm này cũng không tạo ấn tượng tốt. Sơ đồ API gateway và AI gateway cũng gần như giống hệt nhau. blog của tailscale: AI-normal
Tôi đang tích cực tìm kiếm một giải pháp thay thế mã nguồn mở cho Tailscale. Nhưng README quá dài dòng, tôi nghĩ sẽ tốt hơn nếu chỉ nén lại phần tổng quan dự án và liên kết tài liệu.
Ưu điểm lớn nhất của Tailscale là kết nối P2P dễ dàng. Còn Octelium thì có vẻ dùng cấu trúc router tập trung, tôi muốn biết có đúng không.
Octelium không phải VPN P2P mà là một kiến trúc zero-trust. Dĩ nhiên nó cũng có thể đóng vai trò VPN truy cập từ xa dựa trên WireGuard/QUIC, nhưng về cấu trúc thì nó gần với Cloudflare Access và Teleport hơn. Kiểm soát truy cập dựa trên L7, truy cập không cần secret (tiêm trực tiếp các loại key/token/API key mà không cần tự phân phối), cấu hình và định tuyến động, khả năng quan sát và audit theo thời gian thực dựa trên OpenTelemetry, v.v. — tất cả những thứ đó về bản chất khác với VPN P2P. Một kiến trúc ZTNA/BeyondCorp nghiêm túc (không tính service mesh) có giới hạn nền tảng nếu triển khai theo dạng VPN P2P. Để có được khả năng quan sát và kiểm soát truy cập theo từng request, bắt buộc phải có proxy nhận biết L7.
Tham khảo thêm, ngay cả Tailscale cũng có trường hợp packet đi qua router tập trung. Giải thích về các loại kết nối của Tailscale
Tôi không hiểu vì sao việc cài cluster k3s lại được nhúng vào ứng dụng. Có lẽ một dạng dễ thêm vào hạ tầng hiện có/CRD đơn giản để expose service sẽ rõ ràng hơn. Bản thân ý tưởng kiểu Cloudflare Access/Teleport mã nguồn mở thì rất hay, nhưng vì hầu hết mọi thứ cuối cùng lại là tùy biến trên k8s, nên nếu tập trung hơn vào các chức năng xoay quanh access thì có lẽ tôi đã quan tâm hơn.
octeliumctl applyhoặc gRPC API rồi có thể quên phần còn lại. Đã từng có thời tài nguyên là CRD, nhưng số lượng loại tài nguyên như user, session, service, namespace (một phần trong số đó tách biệt với namespace của k8s), policy, device, credential, v.v. quá nhiều và lượng dữ liệu quá lớn, khiến backend etcd không ổn định. Cuối cùng họ đã đưa vào một backend Postgres riêng.Đã có quá nhiều dự án tương tự được ra mắt.
Tôi tò mò liệu đây có phải là giải pháp thay thế cho kiểu quản lý truy cập ở cấp độ tập đoàn lớn (corporate botnet) hay không. Nếu tôi là doanh nghiệp lớn, tôi sẽ muốn phần mềm cấp doanh nghiệp cùng gói hỗ trợ để đảm bảo ổn định, nên tôi không rõ một dự án mã nguồn mở do một người phát triển có giải quyết được bài toán đó không.