- Octelium ist eine Open-Source-Plattform der nächsten Generation zum Self-Hosting, die Remote-Access-VPN, ZTNA, API-/AI-Gateway und mehr integriert unterstützt
- Durch Self-Hosting und Single-Tenant-Betrieb bietet sie identitätsbasierte Sicherheitszugriffe auf Anwendungsebene (Layer 7) für alle internen und öffentlichen Ressourcen
- Enthält Funktionen zur Erfüllung moderner Sicherheitsanforderungen wie secret-less Zugriff, fein granulare richtlinienbasierte Kontrolle, zentrales Management und Auditing
- Bietet Wettbewerbsvorteile gegenüber und mögliche Ablösung von verschiedenen bestehenden kommerziellen und Open-Source-Lösungen wie Kubernetes, OpenVPN, Tailscale und Cloudflare Access
- Verfolgt ein Open-Source-Modell und schafft mit kommerziellen Funktionen und Lizenzierung eine geschäftliche Grundlage, mit Fokus auf vollwertiges Self-Hosting
Bedeutung und Überblick des Octelium-Projekts
- Octelium ist eine integrierte Open-Source-Plattform der nächsten Generation für Zero-Trust-Sicherheitszugriff im Self-Hosting, die kommerzielle Lösungen wie Teleport, Cloudflare, Tailscale und Ngrok ersetzen kann.
- Gegenüber bestehenden Open-Source- und kommerziellen Lösungen ist ein großer Vorteil, dass der volle Funktionsumfang ohne Einschränkungen selbst gehostet werden kann und man frei von Zusatzkosten und Vendor Lock-in bleibt.
Was ist Octelium?
- Octelium ist eine integrierte Plattform für Zugriffsmanagement auf Basis von Identität und Layer-7-Algorithmen
- Sie ist eine Alternative für Remote-Access-VPNs (OpenVPN Access Server, Twingate, Tailscale usw.) und deckt zugleich zahlreiche Rollen ab: ZTNA, BeyondCorp (Google BeyondCorp, Cloudflare Access, Teleport usw.), ngrok (Reverse Proxy), API-/AI-Gateway, selbst gehostete PaaS-Infrastruktur, Ersatz für Kubernetes Ingress sowie Homelab-Infrastruktur
- Für den Zugriff von Benutzern (Menschen wie Workloads), Organisationen und Anwendungen werden sowohl ein clientbasierter Ansatz auf Basis von WireGuard-/QUIC-Tunneln als auch clientloser Browser-Zugriff nach dem BeyondCorp-Modell unterstützt
- Kernpunkte sind policy-as-code, bei dem Richtlinien als Code definiert werden, sowie detaillierte kontext- und identitätsbasierte Sicherheit und secret-less Authentifizierung und Autorisierung
Wichtige Anwendungsfälle
- Modernes Remote-Access-VPN: WireGuard-/QUIC-basiert, dynamisch, identitätsbewusst und sicher auf Anwendungsebene
- Aufbau eines integrierten ZTNA-/BeyondCorp-Zugangs
- Self-Hosted Secure Tunnel / Reverse Proxy als Ersatz für ngrok und Cloudflare Tunnel
- Self-Hosted PaaS (Bereitstellung und Skalierung von Container-Apps, anonyme öffentliche Bereitstellung)
- API-Gateway (Alternative zu Kong Gateway, Apigee)
- AI-Gateway (Anbindung von LLM-Providern, identitätsbasierte Kontrolle)
- Integrierter secret-less Zugriff auf SaaS-APIs
- Bereitstellung von Gateway-Infrastruktur für MCP/A2A (Standards für Model Context und Inter-Agent-Kommunikation)
- Erweiterter Ersatz für Kubernetes Ingress / Load Balancer
- Homelab (integrierte sichere Fernverwaltung persönlicher Ressourcen, IoT, Cloud usw.)
Hauptmerkmale
Moderne integrierte Architektur
- Identitätsbewusste Kontrolle auf Anwendungsebene für alle Ressourcen (intern / hinter NAT, öffentlich) und alle Benutzer (Menschen / Workloads)
- Bietet sowohl VPN-basierten Remote-Zugriff als auch clientlosen BeyondCorp-Zugriff
- Läuft auf Kubernetes und bringt horizontale Skalierung und Verfügbarkeit automatisch mit
Dynamischer secret-less Zugriff
- Unterstützt sicheren Zugriff auf zahlreiche Apps/DBs wie HTTP-/gRPC-APIs, Web-Apps, SSH, Kubernetes, PostgreSQL/MySQL ohne Verwaltung oder Weitergabe von Secret Keys
- Auch mTLS-Zugriff ist ohne PKI- oder Zertifikatsteilung möglich
Kontextbewusste, identitätsbasierte Layer-7-Zugriffskontrolle
- Integriertes zentrales, modulares und komponierbares Richtliniensystem (ABAC)
- Unterstützt Policy-Sprachen wie CEL und OPA; ermöglicht fein granulare Kontrolle jeder einzelnen Anfrage
Dynamisches Routing / Konfiguration
- Richtlinienbasiert sind unterschiedliche übergeordnete Kontexte, Accounts und bedingtes Routing für dieselbe Ressource möglich
Kontinuierlich starke Authentifizierung
- Integration mit Standard-IdPs wie OpenID Connect und SAML2.0
- Workloads authentifizieren sich secret-less mit OIDC-Tokens
- Unterstützt NIST-Authentifizierungsstufen, MFA und Phishing-Schutz (Passkeys, YubiKey usw.)
Tiefe Transparenz und Auditing auf Anwendungsebene
- OpenTelemetry-Integration mit Echtzeit-Protokollierung aller Anfragen und Weiterleitung an externe OTLP-Collector
Serverless SSH und Bereitstellung von Container-Apps
- SSH-Zugriff auf Container, IoT und Hosts ohne SSH ohne Root-Rechte
- Unterstützt PaaS-ähnliche Bereitstellung, Skalierung und sicheren Zugriff für Container-Apps
Zentrales deklaratives Management und programmierbare Steuerung
- Deklarative Verwaltung wie bei Kubernetes; Cluster-Zustand lässt sich mit einem einzelnen Befehl oder per Code reproduzieren
- DevOps-/GitOps-freundlicher Betrieb über die
octeliumctl-CLI und die gRPC-API
Keine Netzwerkänderungen erforderlich und Lösung typischer VPN-Probleme
- Upstream-Ressourcen müssen von der Existenz von Octelium nichts wissen; Dienste können sicher hinter NAT ohne geöffnete Ports betrieben werden
- Automatisiert Einstellungen wie dedizierte Dual-Stack-Private-IP und Private DNS
Vollständig Open Source, Self-Hosted und ohne Vendor Lock-in
- Vollständiger Quellcode offen, keine Funktionsbeschränkungen der kommerziellen Version und kein Vendor Lock-in
- Unterstützt skalierbare Konfigurationen vom Mini-Cluster auf einem einzelnen Node bis zur großen Cloud-Umgebung
Lizenz und Support
- Der Client-Quellcode steht unter Apache 2.0, der Cluster unter AGPLv3
- Kommerzielle Lizenzierung und Enterprise-Support verfügbar; externe Beiträge derzeit eingeschränkt
- Community-Support über offizielle Dokumentation, Discord, Slack, E-Mail, Reddit usw.
Zusammenfassung wichtiger Punkte aus den häufig gestellten Fragen
- Derzeit in der Phase der Public Beta, nach langer interner Entwicklung als Open Source veröffentlicht
- Wird von einem einzelnen Entwickler (George Badawi) vorangetrieben und ohne VC oder externes Kapital eigenständig betrieben
- Kann die Rolle eines VPNs übernehmen, zielt aber grundsätzlich auf ZTA auf Basis eines identitätsbewussten Proxys
- Es gibt keine Einschränkungen, die „nicht wirklich nach Open Source aussehen“, und keinen Zwang zu kommerziellen Produkten; das Designziel ist Self-Hosting mit vollem Funktionsumfang
- Das Geschäftsmodell leitet sich ab aus technischem Support, kommerzieller Lizenzierung und zusätzlichen Enterprise-Funktionen (z. B. SIEM-Integration, Vault-Backend, EDR)
1 Kommentare
Hacker-News-Kommentare
Für alle, denen es schwerfällt zu verstehen, was Octelium eigentlich macht: Ich habe die bisher klarste Erklärung gefunden und teile sie hier: Der Link How Octelium Works - offizielle Dokumentation ist am leichtesten verständlich. Anstatt alle denkbaren Funktionen von Octelium aufzuzählen und dadurch Verwirrung zu stiften, beginnt die Erklärung mit den Kernkonzepten und führt schrittweise weiter, was sehr ansprechend ist. Die Hauptfunktionen sind ein VPN-ähnliches Gateway, das fortgeschrittene Protokolle versteht und inhaltsbasierte, feingranulare Sicherheitsentscheidungen treffen kann, sowie eine auf Kubernetes aufgebaute Cluster-Konfigurationsebene. Beides zusammen ergibt eine Art „persönliche Cloud“. Es bietet wie große Cloud-Plattformen sehr viele Funktionen, sodass man schwer entscheiden kann, womit man anfangen soll. Es ist ein cooles System mit Einsatzmöglichkeiten für das private Homelab, kleine Firmen, die Cloud-Kosten senken wollen, oder ein maßgeschneidertes PaaS.
TailScale ist zwar zufriedenstellend, aber ich sehe die Notwendigkeit von Konkurrenz. Ein IPO scheint absehbar zu sein, und wenn es so weit ist, könnten die Preise ohne Wettbewerber stark ansteigen.
Man kann es als eine programmierbare Network-Tunnel-Fabric zusammenfassen.
Aus meiner Sicht gibt es einige Probleme und deshalb gute Gründe, warum Nutzer skeptisch bleiben. Die fehlende Entwicklungshistorie, ein unbekannter riesiger erster Commit, wenig öffentliche Informationen, keine klar erkennbare reale Firma, Marketing mit dem Anspruch, alles lösen zu können, und Sicherheitsversprechen ohne Belege untergraben das Vertrauen. In dieser Situation braucht es mehr Informationen dazu, ob es sich um echte Eigenentwicklung handelt oder um etwas, das auf ausreichend vertrauenswürdiger bestehender Technologie aufbaut. Wenn es als Geschäft auf den Markt gebracht werden soll, muss Glaubwürdigkeit hergestellt werden. Wenn es dagegen ein privates Projekt ist, kann das Auftreten als Business eher wie ein Fake/Scam/Warnsignal wirken. Es fällt schwer, positiv darauf zu reagieren, dass ein Einzelentwickler plötzlich ein Produkt veröffentlicht, das mit großen Unternehmen konkurrieren soll. Es ist wichtig, Sicherheit klar herauszustellen. Wenn sich der Zweck der Software nicht einmal in einem Satz erklären lässt, steht ein harter Kampf bevor. Noch mehr Funktionen aufzuzählen ist nicht die Lösung. Eher entsteht ein Eindruck wie „installier mich einfach blind“, was die Motivation senkt, es überhaupt auszuprobieren. Das dürfte den Erfolg des Projekts eher behindern.
Das ist hervorragendes Feedback. Ich verstehe die Berechtigung der Kritik, denn Octelium wurde absichtlich so entworfen, dass es viele Funktionen gleichzeitig erfüllt. Octelium ist eine integrierte/allgemeine Zero-Trust-Access-Plattform, die in vielen Szenarien zwischen Mensch und Workload sowie zwischen Workload und Workload eingesetzt werden kann (die Dokumentation enthält dazu viele detaillierte Beispiele). Deshalb kann es für neue Nutzer verwirrend wirken. Dass der erste Commit plötzlich auftauchte, liegt daran, dass tatsächlich schon seit Anfang 2020 daran entwickelt wurde, man sich aber bei der Code-Veröffentlichung wegen möglicher Leaks persönlicher Informationen für ein sauberes öffentliches Repository ohne frühe Commits entschieden hat. In den letzten fünf Jahren gab es fast 9.000 manuelle Commits, und anfangs war es nur ein einfaches Remote-Access-WireGuard-VPN, das sich inzwischen vollständig in Architektur, Funktionsumfang und Komplexität zu dem heutigen Stand gewandelt hat.
Open-Source-Entwicklern sollte man großzügiger begegnen. Niemand kennt den Hintergrund oder die Motivation des OP, vielleicht macht er es einfach aus Spaß. Das muss nicht gerechtfertigt werden. Es ist Open Source und freie Software. Zur Kritik, man könne die Benutzerbeschreibung nicht in einem Satz liefern: Man kann es relativ einfach mit tailscale, cloudflare access oder ngrok vergleichen. Wenn man solche Produkte ohnehin nicht braucht, braucht man dieses Produkt von vornherein ebenfalls nicht.
Ich habe mir Octelium kürzlich angesehen, und es scheint so, als sei bei der Installation ein Kubernetes-Cluster zwingend erforderlich. Falls das stimmt, ist die Einstiegshürde viel zu hoch. Wir möchten Nodes an ein Overlay-Netzwerk anbinden und keine zusätzlichen Infrastrukturabhängigkeiten wie k8s einführen. Gerade bei internen Services sollte es möglichst wenige oder gar keine Abhängigkeiten geben, deshalb erscheint mir diese Entscheidung seltsam. Wenn SDN auf einem Cluster nötig ist, mag das die Zielgruppe sein, aber ich frage mich, ob es nur dafür gedacht ist. Ich hoffe, dass die k8s-Integration optional ist und keine feste Voraussetzung oder der einzige Deployment-Weg. Falls es Material dazu gibt, Octelium ohne k8s zu verwenden, wäre ich dankbar.
octeliumctl applyalle Services automatisch deployen, verwalten, skalieren und wieder abbauen kann. Manuelle Arbeiten wie das Öffnen von Firewall-Ports sind nicht nötig. So wie Kubernetes Container verwaltet, orchestriert Octelium auf dieselbe Weise automatisch Services, Proxys usw. Auch komplexe Verwaltung etwa der Node-Anzahl oder von CRI-Networking ist nicht erforderlich. Der Cluster umfasst alle Nodes und lässt sich deklarativ bzw. programmatisch verwalten. Für den Betrieb von Octelium ist überhaupt kein tiefes Kubernetes-Wissen nötig; abgesehen von bestimmten Aufgaben wie dem Skalieren des k8s-Clusters selbst oder dem Einrichten von TLS-Zertifikaten arbeitet man nur mit Octelium. Für mehr Details wird ein Blick in die offizielle Dokumentation empfohlen.Ich entwickle sofort großes Misstrauen, wenn zu viele Buzzwords herausgehauen werden. Selbst auf der GitHub-Seite verstehe ich nicht richtig, was das Produkt konkret macht.
Insgesamt gibt es mit Tinc, Hamachi, ZeroTier, Nebula, Tailscale, Netbird usw. schon zu viele ähnliche Produkte. Jedes hat seine Vor- und Nachteile, aber in der Praxis halte ich die tatsächlichen Unterschiede für gering. Was ich persönlich wirklich will, ist ein Zero-Trust-„Lighthouse“. Bei Zerotier und Tailscale hat der Dienst die Berechtigung, Nodes zu meinem Account/Netzwerk hinzuzufügen. Ich will vollständiges Self-Hosting und eine Lighthouse-Struktur, bei der der Lighthouse nicht Teil des Netzwerks ist, sondern nur die Nodes überwacht. Ich werde dazu noch weiter recherchieren.
Beim Lesen der Dokumentation hatte ich den Eindruck, dass viele Leute den eigentlichen Wert von Octelium übersehen. Wenn es tatsächlich so funktioniert, wie in der Dokumentation beschrieben, könnte es ein unentdecktes Juwel sein. Was Enterprise-Kunden wollen, ist eine Abkehr von klassischer perimeterbasierter Sicherheit hin zu dem Konzept, das Google mit überProxy/BeyondCorp beschrieben hat (und das inzwischen durch allerlei Buzzwords verwässert wurde): eine saubere Trennung zwischen Produktionssystemen, internem Unternehmensnetz und externem Internet, eine für interne Mitarbeiter möglichst transparente UX, klar kontrollierte Berechtigungen für Traffic, der diese Grenzen passiert, und starke Identitätsauthentifizierung für alle Clients. Außerhalb von Google ist man wegen der Vielfalt von Protokollumgebungen stark eingeschränkt. Protokollbewusste Proxys können mit klassischen coarse-grain-Entscheidungen und Logging arbeiten, aber wenn sogar Typinferenz unterstützt wird, werden deutlich präzisere Berechtigungskontrollen auf Request-Ebene möglich (weil die Bedingungen jeder Anfrage der Policy Engine offengelegt werden). Die Dokumentation ist langatmig und das Marketing nicht besonders glatt, aber das Problem selbst ist so komplex, dass es bisher niemand vollständig gelöst hat. Teleport war bei OSS und Kommerzialisierung am schnellsten, StrongDM unternimmt ebenfalls interessante Versuche. Ich würde mir wünschen, dass Hashicorp hier ebenfalls stärker investiert. (*meine persönliche Meinung)
Octelium kann die oben genannten Produkte zwar ersetzen, aber Ausrichtung und Einsatzweise sind breiter und klar auf Zero Trust fokussiert. Es ist mehr als nur ein simples VPN-/Remote-Access-Tool. Ich würde dringend empfehlen, die Dokumentation zu lesen, um Absicht, Architektur und Funktionsumfang zu verstehen. Heute bewirbt sich praktisch jedes Produkt als „Zero Trust“, aber echte ZTA nach NIST-Definition (also L7-bewusste Proxys, Policy Decision Points, request-spezifische feingranulare Zugriffskontrolle auf Policy-Code-Basis, zentralisierte Identität, Integration externer SIEM-/SSO-/Threat-Intelligence-Tools usw.) gibt es nur bei wenigen. Zu den kommerziellen Produkten, die man tatsächlich als „echtes“ ZTA einordnen kann, gehören Cloudflare Access, Teleport, Google BeyondCorp, StrongDM und Zscaler. Im Gegenteil verwässern Unternehmen den Begriff durch Übernutzung inzwischen stark und lösen das Konzept von „echtem Zero Trust“ immer weiter auf.
Sieh dir den Cathedral-Modus von sanctum an. Vollständig Self-Hosting ist möglich, und die Nodes übernehmen nur Discovery. Sobald der Tunnel steht, ist der Cathedral-Node nicht mehr beteiligt, außer bei der Verteilung von Black Keys oder wenn ein Peer hinter NAT sitzt. Es gibt auch reliquary. Ich betreibe es selbst. sanctum, reliquary
Eine größere Liste verwandter Projekte findet sich unter awesome-tunneling.
Ich verstehe, dass das Einfügen des Stichworts „AI“ SEO-Zwecken dient. Das ist ein bisschen so, als würde man „Reddit“ an einen Artikeltitel hängen. Selbst wenn der Inhalt gut ist, hinterlässt diese Art keinen guten Eindruck. Auch die Diagramme für API Gateway und AI Gateway sind fast identisch. tailscale-Blog: AI-normal
ext_prockommt bald, und Unterstützung für proxy-wasm soll je nach Nachfrage ebenfalls ergänzt werden. Siehe auch die HTTP-bezogene Erklärung.Ich suche aktiv nach einer Open-Source-Alternative zu Tailscale. Aber das README ist viel zu lang; besser wäre eine komprimierte Darstellung nur mit Projektüberblick und Dokumentationslinks.
Der größte Vorteil von Tailscale ist die einfache P2P-Verbindung. Bei Octelium scheint stattdessen eine zentralisierte Router-Struktur verwendet zu werden; ich frage mich, ob das korrekt ist.
Octelium ist kein P2P-VPN, sondern eine Zero-Trust-Architektur. Natürlich kann es auch als Remote-Access-VPN auf Basis von WireGuard/QUIC dienen, strukturell liegt es aber näher bei Cloudflare Access oder Teleport. L7-basierte Zugriffskontrolle, secretloser Zugriff (Injection statt direkter Verteilung von Schlüsseln, Tokens, API-Keys usw.), dynamische Konfiguration und Routing sowie Echtzeit-Observability und Auditing auf Basis von OpenTelemetry unterscheiden es grundlegend von einem P2P-VPN. Eine echte ZTNA-/BeyondCorp-Architektur (abgesehen von Service Mesh) lässt sich in Form eines P2P-VPN grundsätzlich nur begrenzt umsetzen. Um request-spezifische Zugriffskontrolle und Sichtbarkeit zu erreichen, braucht es zwingend einen L7-bewussten Proxy.
Zur Einordnung: Auch bei Tailscale laufen Pakete in manchen Fällen über zentralisierte Router. Erklärung der Connection Types von Tailscale
Ich verstehe nicht, warum die Installation eines k3s-Clusters in die App eingebaut ist. Eine Form, die sich einfach zur bestehenden Infrastruktur hinzufügen lässt, oder ein simples CRD zum Exponieren von Services, wäre viel klarer. Das Konzept eines Open-Source-Cloudflare-Access-/Teleport-Äquivalents ist an sich cool, aber da die meisten am Ende nur Kubernetes-Customizing sind, hätte ich mehr Interesse, wenn der Fokus stärker auf Access-Funktionen läge.
octeliumctl applyoder die gRPC-API und kann den Rest vergessen. Früher waren die Ressourcen CRDs, aber weil es zu viele Ressourcen wie Nutzer, Sessions, Services, Namespaces (teilweise getrennt von k8s-Namespaces), Policies, Devices, Credentials usw. gab und das Datenvolumen zu groß wurde, erwies sich das etcd-Backend als instabil. Deshalb wurde schließlich ein separates Postgres-Backend eingeführt.Es gibt schon zu viele ähnliche Projekte, die bereits veröffentlicht wurden.
Ich frage mich, ob das ein Ersatz für Access-Management auf Großkonzern-Niveau (Corporate Botnet) sein soll. Wenn ich ein Großunternehmen wäre, würde ich aus Stabilitätsgründen Software und Supportpakete von einem Großunternehmen wollen; ich bin nicht sicher, ob ein Open-Source-Projekt das Problem eines einzelnen Entwicklers lösen kann.