- Octelium は、リモートアクセス VPN、ZTNA、API/AI ゲートウェイなどを統合的にサポートする次世代のオープンソース・セルフホスティングプラットフォーム
- セルフホスティングおよびシングルテナントで、あらゆる内部・公開リソースに対するアイデンティティベースのアプリケーション層（レイヤー 7）セキュアアクセスを提供
- シークレットレス（secret-less）アクセス、きめ細かなポリシーベース制御、集中管理と監査など、最新のセキュリティ要件を満たす機能を含む
- 既存の Kubernetes、OpenVPN、Tailscale、Cloudflare Access などの各種商用/オープンソースソリューションに対して優位性を提供し、代替可能
- オープンソースモデルを採用し、商用機能の提供とライセンスで事業基盤を構築しつつ、フル機能のセルフホスティング提供に重点を置く
Octelium プロジェクトの重要性と概要
- Octelium は、Teleport、Cloudflare、Tailscale、Ngrok のような商用ソリューションを置き換えられる次世代のオープンソース統合 Zero Trust セルフホスティング型セキュアアクセスプラットフォームである。
- 既存のオープンソース/商用ソリューションに比べ、機能を損なうことなく全面的に自前でホスト可能で、追加コストやベンダーロックインから自由である点が大きな強みである。
Octelium とは何か
- Octelium は、アイデンティティベース・レイヤー 7 アルゴリズムを適用した統合アクセス管理プラットフォーム
- リモートアクセス VPN（OpenVPN Access Server、Twingate、Tailscale など）の代替であると同時に、ZTNA、BeyondCorp（Google BeyondCorp、Cloudflare Access、Teleport など）、ngrok（リバースプロキシ）、API/AI ゲートウェイ、セルフ PaaS インフラ、Kubernetes Ingress の代替、Homelab インフラなど、さまざまな役割に対応する
- ユーザー（人・ワークロードの両方）・組織・アプリケーションへのアクセスのために、WireGuard/QUIC トンネルベースのクライアント方式と、BeyondCorp 方式のクライアントレスなブラウザアクセスの両方をサポートする
- ポリシーをコードで定義する policy-as-code と、詳細なコンテキスト・アイデンティティベースのセキュリティ・シークレットレスな認証および認可が中核である
主なユースケース
- モダンなリモートアクセス VPN: WireGuard/QUIC ベース、動的・アイデンティティ認識・アプリケーション層セキュリティ
- 統合 ZTNA/BeyondCorp アクセス構成
- セルフホスティングのセキュアトンネル/リバースプロキシ（ngrok、Cloudflare Tunnel の代替）
- セルフホスティング PaaS（コンテナアプリのデプロイ・スケーリング・匿名公開ホスティング）
- API ゲートウェイ（Kong Gateway、Apigee の代替）
- AI ゲートウェイ（LLM プロバイダー接続・アイデンティティベース制御）
- 統合シークレットレス SaaS API アクセス
- MCP/A2A（モデルコンテキストおよびエージェント間標準）ゲートウェイインフラの提供
- Kubernetes Ingress/ロードバランサーの高度な代替
- Homelab（個人リソース・IoT・クラウドなどの統合セキュアリモート管理）
主な特徴
モダンな統合アーキテクチャ
- すべてのリソース（内部/NAT 配下、公開）・すべてのユーザー（人/ワークロード）に対応するアイデンティティ認識型、アプリケーション層単位の制御
- VPN ベースのリモート接続と BeyondCorp のクライアントレスアクセスの両方を提供
- Kubernetes 上で動作し、水平スケーリング・可用性を自動で内蔵
動的なシークレットレス（secret-less）アクセス
- HTTP/gRPC API、Web アプリ、SSH、Kubernetes、PostgreSQL/MySQL など多数のアプリ/DB に対して、シークレットキーの管理・共有なしで安全なアクセスをサポート
- mTLS なども PKI/証明書の共有なしでアクセス可能
コンテキスト認識・アイデンティティベース・レイヤー 7 アクセス制御
- 中央集約型でモジュール化・コンポーザブルな**ポリシーシステム（ABAC）**を内蔵
- CEL、OPA などポリシー言語をサポートし、すべてのリクエスト単位で細かな制御が可能
動的ルーティング/構成
- ポリシーベースで、同じリソースに対して異なる上位コンテキスト・アカウント・条件付きルーティングが可能
継続的な強力認証
- OpenID Connect、SAML2.0 などの標準 IdP と連携
- ワークロードは OIDC トークンでシークレットレス認証
- NIST 認証水準・MFA・フィッシング耐性（Passkey、Yubikey など）をサポート
アプリケーション層の深い可視性と監査
- OpenTelemetry 統合により、すべてのリクエストをリアルタイムでログ化し、外部 OTLP コレクターへ送信
サーバーレス SSH とコンテナアプリのデプロイ
- ルート権限不要でコンテナ・IoT・非 SSH ホストにも SSH アクセス
- PaaS に似たコンテナアプリのデプロイ・スケーリング・セキュアアクセスをサポート
集中型の宣言的管理とコード化可能な運用
- Kubernetes のように宣言的に管理し、単一コマンド/コードでクラスター状態を再現可能
octeliumctl CLI と gRPC API により、DevOps/GitOps フレンドリーな運用
ネットワーク変更不要と VPN 固有の問題解消
- アップストリームリソースは Octelium の存在自体を知る必要がなく、ポート開放なしで NAT 配下から安全にサービス運用が可能
- 固有のデュアルスタックプライベート IP、プライベート DNS などの設定を自動化
完全なオープンソース、セルフホスティング・ベンダーロックインなし
- 全ソースを公開し、商用版での機能制限や Vendor Lock-in はない
- 単一ノードのミニクラスターから大規模クラウドまで拡張可能な構成をサポート
ライセンスとサポート
- クライアントソースは Apache 2.0、クラスターは AGPLv3
- 商用ライセンスとエンタープライズサポートがあり、外部コントリビューションは現在制限されている
- 公式ドキュメント、Discord、Slack、メール、Reddit などでコミュニティサポート
よくある質問の主な項目まとめ
- 現在は Public Beta 段階で、長期間の内部開発を経てオープンソース化された
- 1 人の開発者（George Badawi）が主導しており、VC や外部資本なしで独自運営中
- VPN として利用可能だが、根本的にはアイデンティティ認識プロキシベースの ZTA を志向している
- 実際には「オープンソースらしくない」制約や商用への強制はなく、セルフホスティング・フル機能提供が設計目標である
- ビジネスモデルは、**技術サポート、商用ライセンス、エンタープライズ追加機能（例: SIEM 連携、Vault バックエンド、EDR）**などから派生する
1件のコメント
Hacker Newsの意見
Octeliumが何をするものなのか理解しにくい人向けに、最も明快な説明が見つかったので共有する。Octeliumの仕組み - 公式ドキュメント のリンクが一番わかりやすい。Octeliumについて考え得る機能をすべて列挙して混乱させるのではなく、コア概念から始めて段階的に説明する方式が魅力的。主要機能は、高度なプロトコルを理解しつつ内容ベースで細かなセキュリティ判断を下せるVPN風ゲートウェイと、Kubernetes上に構築されたクラスター設定レイヤーである。この2つが組み合わさって「個人用クラウド」を作る形になる。大規模クラウドプラットフォームのように非常に多くの機能を提供するが、どこから使い始めるべきか判断が難しい。個人ホームラボ、クラウドコストを削減したい小規模企業、カスタムPaaSなど、さまざまに活用できそうな魅力的なシステムだ。
TailScaleには満足しているが、競合の必要性は感じる。IPOが予想されているが、その段階に入ると競争相手がいない場合、価格が急激に上がる可能性が高いと思う。
プログラマブルなネットワークトンネルファブリックと要約できる。
個人的に見ていくつか問題点があり、そのためユーザーが懐疑的にならざるを得ない理由を共有する。開発履歴の欠如、正体不明の大規模な初回コミット、公開情報の不足、実在する会社に見えないこと、何でも解決できると主張するマーケティング、裏付けのないセキュリティなど、さまざまな点で信頼を損ねている。この状況では、本当に独自技術なのか、あるいは十分に信頼できる既存技術の上に構築されているのか、追加情報が必要だ。事業として出すなら信頼性を確保しなければならない。一方で個人プロジェクトなら、ビジネスであるかのように振る舞う姿勢が、むしろ偽物・詐欺・注意信号に見える可能性があると助言する。1人の開発者が大手企業と競合する製品を突然出してきたという点について、前向きには受け取りにくい。セキュリティを明確に打ち出すことが重要だ。ソフトウェアの目的を一文で説明することすら難しいなら、厳しい戦いになるだろう。機能をさらに多く並べることが解決策ではない。むしろ「とにかく入れてくれ」という感じがして、試す理由を失わせる効果をもたらす。これがプロジェクト成功の妨げになる可能性が高いことを指摘する。
素晴らしいフィードバックだ。Octeliumが多様な機能を同時にこなすよう意図的に設計されているという点で、この批判が正当であることは理解できる。Octeliumは、人間対ワークロード、ワークロード対ワークロードの複数ケースで使える統合的・汎用的なゼロトラストアクセスプラットフォームだ（ドキュメントにさまざまな例が詳しくある）。そのため、初めて使う人にとって混乱し得る。初回コミットが突然現れたのは、実際には2020年初頭から開発していたものの、コード公開を決めた際に個人情報流出のリスクを避けるため、初期コミットを含まないクリーンな公開リポジトリとして始めたからだ。過去5年間でほぼ9,000件の手作業コミットを行っており、初期には単純なリモート接続用WireGuard VPNだったが、現在のアーキテクチャ、機能、複雑さへと完全に変化した。
オープンソース開発者には寛容さが必要だ。OPの背景や動機を誰も知らず、単に楽しみでやっているだけかもしれない。正当化する必要はない。これはオープンソースかつフリーソフトウェアだ。ユーザー向け説明を一文でできないという批判については、tailscale、cloudflare access、ngrokのように比較的シンプルに説明できる。こうした製品が必要でないなら、そもそもこの製品も必要ない。
最近Octeliumを見てみたが、インストール時にKubernetesクラスターが必須のように見える。もしそうなら参入障壁が高すぎる。こちらはオーバーレイネットワークにノードをつなぎたいのであって、k8sなど別のインフラ依存を増やしたいわけではない。内部サービス依存は最小、あるいは不要であるべきという点から、この選択は不可解だ。SDNがクラスター上に必要ならそれがターゲットなのかもしれないが、それだけなのか気になる。k8s統合がオプションであって、必須前提や唯一のデプロイ方法でないことを願う。もしk8sなしでOcteliumを使う資料があれば教えてほしい。
octeliumctl applyするだけで全サービスが自動でデプロイ、管理、スケール、撤去までされる。ファイアウォールのポート開放など手動作業は不要だ。Kubernetesがコンテナを管理するように、Octeliumは同様にサービス、プロキシなどを自動調整する。ノード数やCRIネットワーキングなど複雑な管理も必要ない。クラスターがすべてのノードをまたいで宣言的・プログラマブルに管理できる。Octeliumを運用するうえでKubernetesへの深い理解はまったく不要で、k8sクラスター自体のスケールやTLS証明書設定など一部の作業を除けば、Octeliumそのものだけを扱えばよい。詳しくは公式ドキュメントを参照してほしい。バズワードが多すぎて、即座に大きな不信感を抱く。GitHubページを見ても、製品が具体的に何をするのかよくわからない。
全体として、Tinc、Hamachi、ZeroTier、Nebula、Tailscale、Netbirdなど、すでに類似製品が多すぎる。それぞれ長所と短所はあるが、実際には大きな差別化はわずかだと思う。個人的に本当に欲しい機能はゼロトラストの「ライトハウス」だ。ZerotierやTailscaleでは、自分のアカウント/ネットワークにノードを追加する権限をサービス側が持っている。自分が欲しいのは完全セルフホストで、ライトハウスはネットワークの一部ではなく、あくまでノード監視だけを担う構造だ。関連情報をもっと探してみるつもりだ。
ドキュメントを読んでみると、多くの人がOcteliumの本当の価値を見落としている。実際にドキュメントどおりに動くなら、まだ見つかっていない宝石になり得る。エンタープライズが望んでいるのは、既存の境界型セキュリティから離れ、Google überProxy/BeyondCorpが提示した（そして各種バズワードで薄められてしまった）概念、すなわち本番システム、社内、外部インターネットのきれいな分離、社内従業員にとってできるだけ透過的なUX、境界をまたぐトラフィックの権限の明確な管理、すべてのクライアントに対する強力な本人確認だ。Google以外では、多様なプロトコル環境のため制約が大きい。プロトコル認識型プロキシは従来、粗い粒度の判断とロギングしかできないが、型推論までサポートすると、リクエスト単位でより精緻な権限制御が可能になる（すべてのリクエスト条件がポリシーエンジンに公開されるということだ）。ドキュメントは冗長でマーケティングも洗練されていないが、この問題自体があまりにも複雑で、誰も完全には解けていない。TeleportがOSSと商用化で最も早く動き、StrongDMも興味深い試みをしている。Hashicorpにもここへもっと投資してほしいと思う（個人の意見です）。
Octeliumは上で挙げられた製品群の代替にもなり得るが、目指している方向性と活用方法はより広く、明確にゼロトラスト志向だ。単なるVPN/リモートアクセスツール以上のものだ。ぜひドキュメントを読んで、その意図、アーキテクチャ、機能を理解してほしい。最近はどの製品も「ゼロトラスト」と宣伝するが、実際にNISTが定義する本物のZTA（つまりL7認識型プロキシ、ポリシー決定ポイント、ポリシーコードベースのリクエストごとの詳細アクセス制御、中央集権的アイデンティティ、外部SIEM/SSO/Threat intelligenceツール情報の統合など）に当てはまるものは少数だ。実際に「本物の」ZTAと分類できる商用製品は、Cloudflare Access、Teleport、Google BeyondCorp、StrongDM、Zscalerなどだ。むしろ企業がこの用語を乱用し、「本当のゼロトラスト」という概念を希薄化させてしまう傾向が強い。
sanctumのcathedralモードを参照してほしい。完全にセルフホスト可能で、ノードは単にdiscoveryの役割だけを担う。トンネルが確立するとcathedralノードは関与せず、例外的にblack key配布やピアがNATの背後にいるときだけ動作する。reliquaryもある。自分で運用中だ。sanctum, reliquary
さらに多くの関連プロジェクト一覧は awesome-tunneling で確認できる。
「AI」というキーワードの挿入がSEO目的であることは理解できる。記事タイトルに「Reddit」を付けるのと同じようなものだ。内容が優れていても、こういうやり方は良い印象を与えない。APIゲートウェイとAIゲートウェイの図もほぼ同じだ。tailscaleブログ: AI-normal
Tailscaleのオープンソース代替を積極的に探している。ただREADMEが長すぎるので、プロジェクト概要とドキュメントリンクだけを圧縮して見せてほしい。
Tailscale最大の利点は簡単なP2P接続だ。Octeliumはそれと違って中央集権的なルーター構造を使っているように見えるが、正しいのだろうか。
OcteliumはP2P VPNではなく、ゼロトラストアーキテクチャだ。もちろんWireGuard/QUICベースのリモートアクセスVPNとしても機能できるが、構造的にはCloudflare AccessやTeleportにより近い。L7ベースのアクセス制御、シークレットレスアクセス（各種キー/トークン/APIキーなどを直接配布せず注入）、動的設定とルーティング、リアルタイムのOpenTelemetryベース可視性と監査など、P2P VPNとは本質的に異なる。本格的なZTNA/BeyondCorp構造（サービスメッシュを除く）は、P2P VPN形式で実装するには根本的な限界がある。リクエスト単位のアクセス制御と可視性確保には、必ずL7認識型プロキシが必要だ。
参考までに、Tailscaleもパケットが中央集権的ルーターを通る場合がある。Tailscaleのconnection types説明
k3sクラスターのインストールがアプリに組み込まれている理由が理解できない。既存インフラに簡単に追加できる形、あるいはシンプルなCRDでサービス公開するほうがわかりやすい気がする。オープンソースのCloudflare Access/Teleportのようなコンセプト自体は魅力的だが、大半が結局k8s上のカスタムになっていて、アクセス中心の機能に集中していたらもっと関心を持てたと思う。
octeliumctl applyやgRPC APIを通じて宣言的にリソースを作成/削除すれば、あとは管理を忘れてよい。リソースがCRDだった時期もあったが、ユーザー、セッション、サービス、ネームスペース（この一部はk8sネームスペースとは別）、ポリシー、デバイス、認証情報など、リソースが多すぎてデータ量も大きく、etcdバックエンドが不安定だった。最終的に別個のPostgresバックエンドを導入した。すでに公開されている似たようなプロジェクトが多すぎる。
大企業レベルのアクセス管理（コーポレートボットネット）の代替なのか気になる。もし自分が大企業なら、安定性のために大手ベンダーのソフトウェアとサポートパッケージを求めるだろうし、1人開発のオープンソースプロジェクトがその問題を解決できるのかよくわからない。