11 ms·

Show HN: Octelium – FOSS Alternative to Teleport, Cloudflare, Tailscale, Ngrok

• kosolam 1y ago
  It looks very interesting, but I’m getting lost in the pages of features and different use cases. It would have been nice to have a succinct list of features/capabilities (technical, not buzzword) and why this solution solves better than alternatives.
  • geoctl 1y ago
    Thank you. I understand it's hard to concisely define what Octelium is because it is designed as a unified/generic secure/zero trust access platform, a term that almost nobody would relate to. It's more of a generic Kubernetes-like architecture/infrastructure for zero trust secure access that can fit many different use cases (i.e. human to workload and workload to workload environments). Well, it can be used as a typical WireGuard/QUIC-based remote access/corporate VPN. It can be used as a ZTNA/BeyondCorp platform with identity-based, L7 aware, context-aware ABAC via policy-as-code with CEL and OPA where you can control access at layer-7 (e.g. HTTP request headers, serialized JSON body content, etc...). It can also be used as an ngrok alternative (both secure access via OIDC/SAML/GitHub IdP as well as anonymously which can fit for hosting, testing APIs, etc...). It can also deploy your containerized resources and automatically provide client-based/clientless secure access to them (kinda like a PaaS) and it does provide dynamic configuration and routing to upstreams via policy-as-code (e.g. route to different API versions, use different SSH credentials, different API keys, different postgres user/password based on identity/context, etc....). It can also fit as an API/AI gateway and a scalable infrastructure for MCP architectures/meshes. Therefore, it's not really a ZTNA/VPN in the rigid sense, it's a more generic platform where what it does to secure/remote access is similar to what Kuberentes does for containers.
    • alienbaby 1y ago
      Perhaps it would be easier to go through a few typical use cases and implementations, and describe how they work with less brand naming and technical fancywords. I scanned the github, and your reply above, and I still don't really get it. I imagine I would understand it better if I was more fluent in the vocabulary you use and understood what some of the platforms and interesting names did from the get go. So yea, my 2p - break it down into some use cases from simple - intermediate - advanced, use more straight forward language and less platform / product names. Technical terms are fine, but try not to string a zillion of them together all in one go... it reads a bit too much like a sales pitch trying to cram in as many acronyms and cool sounding things as possible.
      • geoctl 1y ago
        I honestly don't understand where the "sales pitch" part is. This project has been so far a solo effort and I am the one who basically wrote all the code. It's not like this is some VC-backed product where I am a marketing guy replying to you. I would appreciate it if you could provide me direct questions about what you don't understand so that I can answer you.
        • homarp 1y ago
          define all the terms. explain simple use cases. explain why you built it, how you use it. explain the 'size' of it (it requires k8s so might not be for my small homelab) compare to 'similar' offerings.
      • reachableceo 1y ago
        I do agree with that. As a potential customer , reading over the page, it was incredibly redundant / dense. I recommend using an LLM to rewrite it far more succinctly.
    • reachableceo 1y ago
      Please update your HN profile with contact information. This product? Framework? Solution? seems to be exactly what I’ve been looking for / attempting to put together for my company. We are entirely self hosted and use only FLO software. We use Cloudron as our core PAAS and have been looking for a FLO zero trust / identity aware proxy for DB/RDP/SSH . Happy to be your flagship customer. We have a brand new k8s (self hosted) cluster deployed . We use wazuh as our SEIM, librenms for monitoring / alerting. Currently we use tailscale (with magicdns disabled and we hand out our internal pi hole IP as our recursive DNS server ) (and we have an authoritative DNS for our internal corporate domain). Charles@turnsys.com reaches me pretty quickly most days. Would love to deploy this immediately and write a testimonial etc
• yjftsjthsd-h 1y ago
  The big thing to me about Tailscale is easy p2p connectivity. I think it looks like this doesn't do that and uses centralized router(s)?
  • geoctl 1y ago
    Octelium is a zero trust architecture not a p2p VPN even though it can seamlessy operate as a WireGuard/QUIC-based remote access VPN among other things. Its architecture is closer to Cloudflare Access, Teleport, etc... as it provides dynamic L7-aware access control, secret-less access (i.e. injecting API keys and access tokens, database passwords, SSH private keys, mTLS private keys etc... without distributing them to Users), dynamic configuration and routing to upstreams, etc... via identity-aware proxies as opposed to just merely operating as a VPN at layer-3 as well as to providing OpenTelemetry-native visibility and auditing in real-time. True zero trust architectures such as ZTNA/BeyondCorp, apart from service meshes (e.g. Kubernetes service meshes), are problematic to be implemented as p2p VPNs to say the least. You simply need L7-aware identity-proxies to do the process of access control and visibility at the application-layer on a per-request basis.
  • gen6acd60af 1y ago
    >easy p2p connectivity >centralized router(s) When using Tailscale, your packets may be sent through centralized routers, FYI. https://tailscale.com/kb/1257/connection-types https://tailscale.com/kb/1257/connection-types
  • ethan_smith 1y ago
    Looking at the docs, Octelium uses a hub-and-spoke model with Gateways acting as central routing points, unlike Tailscale's direct peer-to-peer mesh - this architectural difference impacts performance, privacy, and deployment complexity.
    • geoctl 1y ago
      No, Octelium does not use a hub-and-spoke model. It's a distributed system that's a horizontally salable architecture on top of Kubernetes. This design is meant to provide seamless horizontal scalability and availability, among other things.
• mzhaase 1y ago
  I have an immediate complete distrust to anything that throws around so many buzzwords. This is the github page and I still don't understand what it even does, specifically.
  • geoctl 1y ago
    I'd appreciate if you could provide me a list of those buzzwords so that I can improve the readme.
    • drexlspivey 1y ago
      “A next-gen FOSS self-hosted unified zero trust secure access platform that can operate as a remote access VPN, a ZTNA/BeyondCorp architecture, API/AI gateway, a PaaS, an infrastructure for MCP & A2A architectures or even as an ngrok-alternative and a homelab infrastructure.” Literally every single word of it
      • geoctl 1y ago
        I admit that the "next-gen" word might sound cheesy. As I said in the other reply, the more correct definition for Octelium is: a unified zero trust secure access platform. However, as I said this is a term that nobody would relate to. It's a ZTNA/BeyondCorp platform but not in the rigid sense. It's also a WireGuard/QUIC-based remote access VPN but it operates at layer-7 to provide L7 aware access control, secretless access, dynamic configuration and routing as well as OpenTelemtry-native visibility and auditing via identity-aware proxies and policy-decision-points instead of just controlling access at layer-3. As I said, it's designed to be more like a generic Kubernetes-like architecture for secure remote access that can be used for many different use cases.
        • therealpygon 1y ago
          What you took away from that was that “next-gen” was the problem? Buzzwords can still be technically accurate and you seem to be ignoring that when it keeps being confronted. “But it is” doesn’t matter when it comes to “but it sounds like”. Let me give you an example; if I was walk into a store, do you think I want to talk to the person who talks about the “bidirectional optoelectromechanical document transcription and reproduction apparatus implementing discrete photonic acquisition and microdeposition techniques for bidimensional substrate encoding”, or do I want to talk to the person who will sell me a “photocopier”?
• rollcat 1y ago
  I understand adding the "AI" keyword is just SEO, like adding "Reddit" to article headlines... It still leaves a bad taste, even if the main course is excellent. Even the diagrams for API vs AI gateways are almost identical. <https://tailscale.com/blog/ai-normal https://tailscale.com/blog/ai-normal>
  • geoctl 1y ago
    There are lots of common functionalities between API and AI gateways. It would be much easier for you to check out the examples in the docs: For the AI gateway: https://octelium.com/docs/octelium/latest/management/guide/service/ai/ai-gateway https://octelium.com/docs/octelium/latest/management/guide/s... As for the API gateway: https://octelium.com/docs/octelium/latest/management/guide/service/http/api-gateway https://octelium.com/docs/octelium/latest/management/guide/s... I am also working on extending the process of modifying HTTP requests/body content beside what's been provided (see more https://octelium.com/docs/octelium/latest/management/core/service/http https://octelium.com/docs/octelium/latest/management/core/se...). For now, Envoy's ext_proc support is coming, and I might also work on support for proxy-wasm if there is interest in it.
• sneak 1y ago
  As the other commenters have pointed out, your README is offputting. Last year I wrote an article about how to write a good README: https://sneak.berlin/20241224/readme-howto/ https://sneak.berlin/20241224/readme-howto/
  • geoctl 1y ago
    Thank you. I will definitely work on making the README more concise and hopefully more useful and easy to understand.
    • sevg 1y ago
      Your readme isn’t great, but I wouldn’t pay much attention to this guide that this person keeps posting. It’s way too long and excessively prescriptive, and the author goes too far with inserting their opinions (ie, don’t use github, don’t use discord etc.). I couldn’t possibly recommend this howto.
      • sneak 1y ago
        Oh, look, we both have opinions that we each believe are important. Imagine that. :) I think this is the part where I’m supposed to tell third parties to disregard yours, but I’m not going to.
• ar-nelson 1y ago
  For everyone who's having a hard time parsing what Octelium does, I found this page to be the clearest explanation: https://octelium.com/docs/octelium/latest/overview/how-octelium-works https://octelium.com/docs/octelium/latest/overview/how-octel... It's clearer because, instead of starting with a massive list of everything you could do with Octelium (which is indeed confusing), it starts by explaining the core primitives Octelium is built on, and builds up from there. And it actually looks pretty cool and useful! From what I can tell, the core funtionality is: - A VPN-like gateway that understands higher-level protocols, like HTTP or PostgreSQL, and can make fine-grained security decisions using the content of those protocols - A cluster configuration layer on top of Kubernetes And these two things combine to make, basically, a personal cloud. So, like any of the big cloud platforms, it does a million things and it's hard to figure out which ones you need at first. But it seems like the kind of system that could be used for a homelab, a small company that wants to keep cloud costs down, or a custom PaaS selling cloud functionality. Neat!
  • ttul 1y ago
    TailScale is wonderful but they do need competition. I imagine an IPO is on the horizon, and as soon as they enter that phase, nasty price increases are sure to follow unless someone else is nipping hard at their heels.
    • seabrookmx 1y ago
      Hopefully their tolerance to self-hosters (Headscale) doesn't change.
      • wkat4242 1y ago
        The problem is, commercial services will always enshittify. It's inevitable. Even when they conquer the whole market (see Netflix) they will want to see a rising line in profits so then they will turn the thumbscrews on the customers.
        • candrewlee 1y ago
• cedws 1y ago
  Definitely interested in an open source alternative to Tailscale. The README is way too verbose though. It should explain the project at a glance and have links to docs for the details.
  • homarp 1y ago
    headscale is an open source alternative to tailscale: https://github.com/juanfont/headscale https://github.com/juanfont/headscale
    • uneekname 1y ago
      Headscale is great (I use it) but it is an alternative to the Tailscale control server, not the client applications. Some of those are closed source, and their compatibility with Headscale is not guaranteed.
      • CharlesW 1y ago
        Tailscale's client is already open source. https://tailscale.com/opensource https://tailscale.com/opensource: "The core client code for the Tailscale daemon used across all platforms is open source, and the full client code is open source for platforms that are also open source."
        • aspenmayer 1y ago
          So if you are running a closed source OS, Tailscale doesn’t have an open source client? Wouldn’t closed source OS users of Tailscale benefit the most from having an open source Tailscale client available?
          • CharlesW 1y ago
            > So if you are running a closed source OS, Tailscale doesn’t have an open source client? As the content at the link makes crystal clear, the client is open source. Additionally, Tailscale's GUI for that client is open source on open source platforms. 99.999% of users of closed source OSs aren't going to care that the GUI isn't open source. The remaining 0.001% just use the open source client without the GUI.
• therealpygon 1y ago
  Just some feedback to share some problems I personally think you’re going to have and why I suspect you’ll face a healthy amount of skepticism. There is a lack of history of development that ends with a major initial commit of unknown origin, a lack of any public information, a company that does not appear (publicly) to exist, and a product that is going to solve every need that can be imagined by packing it with buzzwords and little to no evidence of security. When faced with those things, my next step would be to consider how much is original versus built on underlying technologies I know and trust; information that is lacking. If you’re launching a business, I would suggest making sure the business looks legitimate; if it’s a pet project, trying to make yourself sound like a big business and then not having the footprint gives off “fake”/scam/caution vibes. If you’re a solo dev, drop all the fake business stuff and get rid of the buzz words and “it can do everything” marketing and focus on what it excels at as an open source project. People are going to be skeptical (rightfully) that a solo dev/no name company is going to suddenly drop a product that rivals those of massive companies. Either massive shortcuts were taken, or there is a high chance that it will be insecure, which is not something you want from a VPN or any of the other things it claims to do. If you’ve built on existing secure technologies, you should emphasizing them because known names that have a security history are going to build a lot more trust than a no-name product. If a software is hard to explain the purpose of to an average person in a single sentence, you have an uphill battle. Listing more features isn’t usually going to be the answer, regardless of how accurate you’re attempting to be. “It’s a VPN! and a PaaS! and a ZTNA! And an API Gateway! and AI!” It screams “please download me” rather than “I’m here to solve a problem“, which is why I wouldn’t even bother to try it; the opposite of what any project is going for. My intention isn’t to just be critical, but rather to point out things that are likely harming your efforts.
  • geoctl 1y ago
    Thank you for your insightful feedback. I completely understand the criticism because Octelium is conciously designed to be many things at the same time. As mentioned in the other replies, Octelium is a unified/generic zero trust access platform that can fit in many human-to-workload and workload-to-workload use cases (the docs contain various examples in detail) that's why it might be confusing for newcomers. The initial commit came out of nowhere because I've been working on this project since early 2020 actually and decided to start with a clean public repo when I publicly released the code a month ago, after nearly 9000 manual commits over the past 5 years. I simply could not verify that I could have potentially leaked private info esepcially in early commits and the project itself almost entirely changed over the past 5 years from a simple remote access WireGuard VPN to what it is today in terms of architecture, features and complexity.
• pydry 1y ago
  Can you use VPNs outside of your infra (e.g. protonvpn, mullvad) as an exit node?
  • geoctl 1y ago
    Interesting. One way to do that in Octelium is via a SOCKS5 proxy served as an Octelium Service. In fact the Octelium Cluster nodes itself can operate as exit nodes directly and you can use that as a form of consumer VPN. You can even deploy and scale TOR containers over Octelium and have load balanced TOR.
    • pydry 1y ago
      This is similar to the current set up I have with tailscale, but it's not ideal, hence why i asked.
      • geoctl 1y ago
        Can I ask you what an ideal setup for your use case would look like? Octelium isn't really concerned with connecting complete remote subnets to each other directly. You can simply use a SOCKS5 proxy as an Octelium Service and do all the access control, dynamic routing and load balancing to that Service representing a specific "VPN".
        • pydry 1y ago
          Basically what tailscale offers with headscale but with more sophisticated control over exit traffic, like: 1) the ability to define an arbitrary wireguard configuration as an exit node (tailscale can do this in theory, but it only works with mullvad and it doesnt work with headscale). 2) the ability to write sophisticated exit traffic rules (e.g. intranet.myemployer.com requests get routed via one home server running my company's proprietary VPN, mybank.com gets routed via another home exit node, default traffic through mullvad, etc.)
          • geoctl 1y ago
• shrubble 1y ago
  One takeaway is that this can replace ZLayer, and it does offer much more functionality than that. Is that correct?
• Onavo 1y ago
  How does it compare to Pangolin?
  • homarp 1y ago
    since I had to ggole it https://github.com/fosrl/pangolin https://github.com/fosrl/pangolin Tunneled Reverse Proxy Server with Access Control - your own self-hosted zero trust tunnel. AGPL3
  • geoctl 1y ago
    Well I haven't used Pangolin myself, but Octelium can basically operate as a similar self-hosted remote access tool. It is designed however, to provide much more than just remote access. It provides L7-aware, context-aware ABAC-based access control, it provides L7-aware secretless access without distributing L7 credentials to users, it provides dynamic routing/configuration to upstreams and upstreams credentials based on identity/context, it provides OpenTemeltry-read L7 aware visibility and auditing. Therefore, it's more closer to Cloudflare Access, Teleport Enterprise, StrongDM, etc... than to Pangolin. However, it's also not just a ZTNA in the rigid sense, for example, your applications written in any programming language can just generate fine-grained bearer authentication access tokens via OAuth2 client credentials flow to access protect Services without having to use clients or special SDKs or being aware of Octelium at all. Octelium also operate on top of Kubernetes which makes it seamless for you to provide horizontal scalability and availability as your Cluster's Services, Users, Sessions and simply traffic grow.
• fariszr 1y ago
  This looks very impressive, but the Readme has way to many details, I think i got the idea but I'm not sure, and that's a problem.
  • geoctl 1y ago
    Thank you. I'd advise you to read how it works https://octelium.com/docs/octelium/latest/overview/how-octelium-works https://octelium.com/docs/octelium/latest/overview/how-octel... and the quick management guide https://octelium.com/docs/octelium/latest/overview/management https://octelium.com/docs/octelium/latest/overview/managemen... to get a clearer idea about how it works and how it's managed. The docs are full of examples for specific use cases too such as https://octelium.com/docs/octelium/latest/management/guide/service/http/nextjs-vite https://octelium.com/docs/octelium/latest/management/guide/s... https://octelium.com/docs/octelium/latest/management/guide/service/http/open-source-self-hosted-ngrok-alternative https://octelium.com/docs/octelium/latest/management/guide/s...
• kevmo314 1y ago
  I’m impressed with how helpful HN commenters are being despite the unilateral opinion about the pitch and readme. For what it’s worth, the title of the post is a pretty good pitch. Leaving it at “FOSS Alternative to …” would be a step in the right direction.
• ghoshbishakh 1y ago
  So this is something like pinggy.io - self hosted?
  • geoctl 1y ago
    Yes, it can operate as a self-hosted ngrok, pinggy, Cloudflare Tunnel with Github/OpenID Connect/SAML SSO and it can also provide anonymous public access, which can be useful for public website/API hosting, among many other use cases. You can see the examples https://octelium.com/docs/octelium/latest/management/guide/service/http/nextjs-vite https://octelium.com/docs/octelium/latest/management/guide/s... and https://octelium.com/docs/octelium/latest/management/guide/service/http/open-source-self-hosted-ngrok-alternative https://octelium.com/docs/octelium/latest/management/guide/s...
• b0a04gl 1y ago
  what if this wasnt something you add after infra but the checkpoint you start with. right now you spin up a vm or db then wrap vpn or firewall around it. but imagine writing access rules first in way : 'team ml can hit service x' or 'web app can hit this backend' and the system wires infra from that.. infra becomes a side effect of access intent. access isnt something you cant guard always( as things move fast, breaks fast), it's may become seed where you can design with.
  • geoctl 1y ago
    If I did understand your point then Octelium actually tries to do what you want to see, at least to a certain extent via managed containers. For example, Octelium can deploy, scale and manage your containerized applications (e.g. web apps, APIs, databases or even PiHole DNS servers) and automatically serve and protect them as Octelium Services. Once you're done with the Service with whatever reason, all the underlying managed container infrastructe is automatically cleaned up. You can see some examples from the docs here: https://octelium.com/docs/octelium/latest/management/guide/service/http/nextjs-vite https://octelium.com/docs/octelium/latest/management/guide/s... https://octelium.com/docs/octelium/latest/management/guide/service/ai/remote-ollama https://octelium.com/docs/octelium/latest/management/guide/s... https://octelium.com/docs/octelium/latest/management/guide/service/homelab/pihole https://octelium.com/docs/octelium/latest/management/guide/s... https://octelium.com/docs/octelium/latest/management/guide/service/homelab/remote-vscode-code-server https://octelium.com/docs/octelium/latest/management/guide/s...
• wkat4242 1y ago
  There are so so many of these already... - Tinc (the OG of P2P VPN) - Hamachi (not open though) - ZeroTier - Nebula (from Slack) - Tailscale - Netbird I wonder why people keep building more. I know each has its own quirks and things they're better at, but the difference is really quite minimal. One of the things I really would like is zero-trust 'lighthouses'. With current Zerotier and Tailscale, you really have to trust them because they can add nodes on your account whenever they want. I don't want that, I want fully self-hosted and for the lighthouses to just coordinate but not to be part of the network. I have to do some research to see what would be best.
  • apitman 1y ago
    And many more: https://github.com/anderspitman/awesome-tunneling https://github.com/anderspitman/awesome-tunneling
  • geoctl 1y ago
    With all respect, regardless of the fact that Octelium can replace the products you just mentioned, its context of interest is much larger and focused towards zero trust rather than just merely a yet another VPN/a remote access tool to access internal resources. I'd really appreciate it if you could read the docs first so that you can understand the features and architecture of Octelium and what it is meant to be. Every product claims to be "zero trust" these days, even VPNs and simple tunneling applications, however, actual zero trust architectures as defined by NIST (i.e. architectures built upon L7-aware identity-aware proxies, policy-decision-points, L7-aware and context-aware per-request access control via policy-as-code and ABAC, centralized identity and policy management, integrating context information from external tools such as SIEM, SSO and threat intelligence tools into per-request access control decisions, etc...) and there are many commercial products that are "true" ZTAs (e.g. Cloudflare Access, Teleport, Google BeyondCorp, StrongDM, Zscaler, etc...). The term is being however abused by the companies, some of which are extremely well funded, to distort reality and the fact that their products were not even built for zero trust. What these fake "zero trust" vendors are trying to achieve is something like: "either we all are zero trust, or zero trust doesn't really exist or mean anything at all and it's merely a buzzword, it's your choice".
• Arch-TK 1y ago
  I just use some tools to automate configuration of a wireguard mesh overlay network. It doesn't seem like it should need to be harder than that.
• thealistra 1y ago
  Is this a replacement for a huge corpo botnet like access control? If I am a huge corpo, don’t I want to have another huge corpo provide me the software with a support package to have some asssurance and not go with the open source option? Not sure if your project solves any issue of a singular dev.
  • geoctl 1y ago
    Octelium itself is designed to be a generic secure access platform that can operate in many environments (from a simple ngrok-tier remote access tool, remote access/corporate VPN up to a full-fledged scalable ZTNA/BeyondCorp platform among many other specific use cases such as API/AI/MCP gateways) at many levels (i.e. dev, startup, enterprise). Think of Kubernetes, you can use it to host a single website running on a single container, you can use it as an API gateway for a few microservices and you can use it as a fully-featured service mesh of hundreds if not thousands of microservices running on tens if not hundreds of nodes with enterprise-level tools such as SPIFFE, Istio, etc...
• guigg 1y ago
  I don't understanding why you're embedding a full k3s cluster install in your app, it would be much clearer to everybody if this was something that you could add to existing infrastructure, with simpler CRDs to expose services. The pitch for the project looks awesome (opensource Cloudflare access / Teleport), but most of the features are customizations on top of k8s anyway, I'd be more interested in testing this if it was focused on the access part.
  • geoctl 1y ago
    Simply an Octelium Cluster is a distributed system that operates on top of k8s. It can work on top of a single-node k8s cluster/k3s which can fit in a small VM/VPS and it can also operate on top of a multi-node "production" k8s cluster. Octelium isn't just some simple abstraction over k8s, Octelium is a complete platform on its own that uses k8s as an infrastructure for itself. It uses its nodes as gateways and hosts for Octelium Services, each Service, represented by an identity-aware proxy that's deployed as a k8s service on the underlying k8s cluster, has a stable private dual-stack IP address(es) depending on the scaling and is basically acting as the endpoint of the other side of the WireGuard/QUIC tunnel. You can now see that Octelium does with identity-aware proxies similarly to what Kubernetes itself does with containers, building a control plane around a scalable data-plane to automatically manage and deploy identity-aware proxies instead of just offloading the work manually to the Cluster administrators which is, I believe the case, in many ZTAs (e.g. Teleport, Pomerium, etc...) which makes the entire system very hard to manage since there is a lot of manual work to do by the administrators of the system. With Octelium, you can simply create and delete Services declaratively via `octeliumctl apply` or directly via the gRPC APIs and forget about managing, deploying and cleaning them up yourself. Actually Octelium resources started as CRDs many years ago, but the amount of resources in the Cluster (e.g. Users, Sessions, Services, Namespaces which are not related to k8s namespaces, Policies, Devices, Credentials, etc...) made it impossible to rely on a the etcd backend, it was simply unreliable for frequently updated resources and resources with large info. So a separate Postgres backend was introduced later.
  • geoctl 1y ago
    One more thing regarding the CRDs. Octelium resources and k8s resources look similar from a YAML perspective. However, Octelium actually use protobuf, all the resources are defined in proto3 and compiled to Go, then the Golang resources are serialized to JSON and stored as JSONB in the Postgres data store of the Cluster. I guess that's another reason you thought that Octelium resources might be CRDs but they actually are not.
• baobun 1y ago
  Looked into Octelium recently and it looks like it depends on or at least assumes a kubernetes kluster for setup. Is this true? If so it makes it a bit of a non-starter for many - we want our nodes on the overlay network, not the other way around. It's a complex dependency for something low-level where we want mininal or no dependencies on other infrastructure or internal services. (Of course there are valid use-cases for SDN on top of the cluster and I guess that's what you're targeting initially but curious if that's also the end of it) Or put another way, I hope that Kubernetes integration is an option, not a prerequisite and the only supported deployment. In case there's already material on Octelium sans k8s that I missed, pointers would be appreciated!
  • geoctl 1y ago
    As as I mentioned in some other reply, Octelium is built as a distributed system on that can operate on top of 1 or more nodes. While Octelium currently must work on top of Kubernetes, Octelium itself is not really that intertwined with k8s, it can actually easily be ported to other orchstrators such as Nomad for example. However, the rationale behind operating as a platform on top of k8s that uses a k8s cluster as an infrastrcuture for itself is to relieve the system administrators from all the manual work that comes with managing zero trust architectures such as manually deploying/scaling/cleaning up the identity-aware proxies. Octelium simply provides both the control plane and data plane where you can just `octeliumctl apply` and all the Octelium Services are deployed/managed/scaled up or down and eventually cleaned up without having to manually run them, open firewall ports, etc... It's very similar to what Kubernetes itself does with containers where a single `kubectl apply` deploys/scales/cleans up all the container changes without having to manually deal with every container in every single node like you would do with docker or containerd. You don't even need to know how many nodes you have or deal with CRI/networking details on every node since a single Cluster spans over all the nodes and does all the work for you whenever you want to apply a new change in the Cluster. This architecture is meant to make the Cluster seamlessly scalable by adding more nodes whenever you want and at the same time can be manageable at any scale decoratively via octeliumctl or programmatically like you would have with a normal k8s cluster. I believe you can understand more by reading how Octelium works in detail in the docs https://octelium.com/docs/octelium/latest/overview/how-octelium-works https://octelium.com/docs/octelium/latest/overview/how-octel... It's also noteworthy to understand that managing an Octelium Cluster doesn't really require any understanding of Kubernetes or how it works, unless for very specific tasks, such as scaling up/down the k8s cluster itself and setting the Cluster TLS cert fed via a specific k8s cert. Apart from that, you're just dealing with Octelium.
• udev4096 1y ago
  Ah yes, use a no-name do-all program for securing my network instead of headscale, a proven and battle tested wireguard mesh
• Tokumei-no-hito 1y ago
  this is incredible OP. nearly every criticism I've read could be resolved by reading the docs for 10-15 mins starting from the "how it works". i did feel uncertain from the README but once i got into the docs i was blown away. this is incredibly well abstracted and organized both in terms of the implementation and docs. to hear that you built this yourself is absolutely legendary. thank you for releasing this.
  • geoctl 1y ago
    Thank you really for your kind comment. Most of the links regarding how Octelium works, the quick management and installation guides, the examples (e.g. API/AI/MCP gateways, etc...) were actually included in the README itself. However, most of the criticism was supposedly coming from the terms used in the README. I was already assuming that the users are somewhat familiar with zero trust and zero trust architectures. Maybe that was the problem.
• meeb 1y ago
  I think a lot of other commentors here are more taking issue with the concept of ZTNs in general and may not have used them at scale, or at all. The intro is buzzword heavy, however I don't think that's an issue with your documentation, just the terminology of the space Octelium operates in which came from big business and was conceived as buzzwords to start with so there's not a lot of flexibility to use alternate terms that make sense. Your documentation is extremely detailed and generally excellent. It does seem to be targeted at people who have already deployed Octelium or are very familiar with ZTN-style deployments. It's quite fractally dense (you stumble over one new term, need to go to another docs page, which is as long, that has more terms you need to read about, etc.) so as you've mentioned the issue really isn't your product but likely conveying what it does in a clear manner. If you want to get general devs and homelabbers on board with the concept or testing this out, which I imagine is a very different target to your initial versions, maybe you could prefix your GitHub readme with something like: "Octelium is a free and open source zero trust network platform. It integrates and manages your Kubernetes (and other container orchestration) applications to provide single point of authentication for all services. Your users log in once to one authentication provider such as a managed provider like Okta or any other OAuth OpenID compatible service and then your users are automatically granted their correct access levels to all your web services, databases, SSH, VPNs and more. Log in once, access everything, self-hosted." When reading your documentation I immediately had a number of questions that were not clearly answered. That doesn't mean to say the answer isn't in your documentation, it's just that after 15-20 minutes of reading I still didn't have a clear answer. I'm reading this from the perspective of someone very familiar with operating Kubernetes clusters at scale and dabbled quite a bit with some of the commercial ZTN offerings. Apologies if the questions below are answered in your docs, I didn't find them in the time I had. 1) Your initial setup guides go from how to install Octelium to immediately scheduling services via YAML as a direct replacement for, I assume, something like deployments on k8s. Does Octelium actually run workloads? Is it 1:1 compatible with k8s API spec? Does it just talk to k8s over the API and effectively rewrite deployment YAML and spam it to k8s? Immediately this has concerns, why do I want this? Do I trust Octelium to manage deployments for me? Replacing a vast part of the k8s stack with Octelium tooling is a big ask for even small companies to trial. There's also just straight upstream connections, why would I want to let Octelium manage workloads over just using an internal k8s service hostname so I don't have to effectively rebuild the entire application around Octelium? Does letting Octelium manage workloads impact anything else (monitoring, logging, any other deployment tools that interact with k8s - if some CI/CD pipeline updates a container image does Octelium "know" or is it out of date?). What about RBAC stuff? Namespaces? Are these 1:1 k8s compatible? 2) If I work for BigCorp I'm going to have things like compliance issues coming out of my ears, your Services store credentials in plain text which is going to be flagged immediately. No-one is going to offload SSH authentication if root SSH keys are stored in plain text in secrets somewhere. I did note there's the option to effectively write your own gRPC interfaces to handle secure secrets storage but this seems like a pretty big hurdle. You then basically say "if you're enterprise we can help here" at the bottom, but I wouldn't even test this myself on a homelab without some sort of more sane basic secret management. 3) How, specifically, does Octelium handle HTTP upstream service issues? For example, if I'm proxying my companies connections to saas.com via saas.myintranet.example.com I assume I lose the ability to apply 2fa to user accounts? It's unclear from the documentation, can I specify unique credentials per user? How would I manage those? Is the only option OAuth and scopes? What if the upstream doesn't support OAuth? It's fine if upstream services need to support OAuth to support the most seamless and secure ZTN-style experience, it's just not that clear how these things work in practice. 4) You re-use a lot of terms from k8s (cluster, service etc.) which are subtly different k8s, this could cause confusion with a lot of k8s trained admins. For example, I believe an Octelium cluster is a k8s cluster running multiple Octelium instances and a custom data plane, this different enough to what a k8s cluster is to potentially be confusing as it's a different logic level. I appreciate there are limited generic descriptive terms in the dictionary to describe these things. 5) How, technically, does some of this stuff work? I know I can browse the repo or read the extensive documentation, but it would be helpful to have some clear "k8s admin"-targeted terms like, we install X proxy that does Y, using Z certificates, services managed by Octelium get a sidecar that intercepts connections to proxy them back into the ZTN, or whatever magic it does in clear, k8s, terms. If I'm looking after something like this I would need to know it inside-out, what if some certificate stops working? If I don't know exactly where everything is how can I debug it? If I deployed this it would be absolutely mission-critical, if it breaks the entire company immediately breaks. If that happens for a couple of days, realistically it can be business-terminating. What would be really helpful to see would be some documentation with step by step guides on going from a starting point to what an Octelium-powered endgame would look like. For example, if I'm the CTO of a business that has some remote managed k8s clusters running our public SaaS along with some tooling/control panels/etc, and then a big server in my office running some non-critical but important apps via Podman, and 15 remote users that currently connect over a Tailscale VPN into the office, and 20+ upstream external web services that provide support ticketing, email, etc. then what does this look like after I "switch" to Octelium? Before and after comprehensive diagrams, and maybe even a little before-video of someone logging in via a VPN then logging into 15 control panels vs an after-video with someone logging into an intranet and just everything magically appearing would be nice. You need to sell something of this scale to CTOs, not engineers. Generally, however, my personal biggest flag with this would be that it requires effectively a total rebuild of all infrastructure, learning entirely new tooling, management and oversight. It's a lot to ask and it doesn't seem like it can be that gradually rolled out. I suppose you could set up a second k8s cluster, deploy Octelium on it and then slowly migrate services over, but that's going to be expensive. Some suggestions: 1) You have built a very impressive toolkit, why not operate this as a SaaS using your toolkit (with on-prem open source extensions)? You don't seem to have an actual product, you have a swiss army knife of ZTN tools which is way more work so hats off to you there. It seems you're partitioning this with "the toolkit is public, write your own glue for free, to get a working platform, come pay us" which is perfectly fine, the issue there is your "enterprise" offerings seem to be even more toolkit options rather than an actual offering. Bundle in some actual enterprise tools (fancy log tool with a web UI that also does user management and connection monitoring as a single dashboard?) and it would be a lot more appealing. 2) You require replacing industry standard technologies like directly managing k8s with kubectl with your own platform and tools - replacing "the way that everyone does X" with "new tool from relatively unknown ZTN provider" is going to be tough to sell. Can you make your octeliumctl tool a kubectl plugin? Could Octelium be less control-everything and just sit on top k8s rather than seemingly replace a lot of it? Edit: 3) Have a homelabber edition, if that's a market you want to target, that's way easier to install and works in a single docker container or something (sacrificing some of the redundancy) but offers a basic complete suite of services (dashboard, HTTP upstream proxying, VPN) with a single "docker run...". Good luck with Octelium, it's certainly interesting and I'll keep an eye on it as it evolves.
• marifjeren 1y ago
  Here is some unsolicited advice on clarity. Pick one or two descriptive phrases per subject. If you need more sentences, that's okay. For example: > Octelium, as described more in detail in the repo's README, is simply an open source, self-hosted, unified platform for zero trust resource access that is primarily meant to be a modern alternative to corporate VPNs and remote access tools. -> "At its core, Octelium is a modern alternative to VPNs. Unlike traditional VPNs, it assumes a zero trust security model. Octelium is open source and built to be self-hosted. The README describes many other use cases and features."
• apexalpha 1y ago
  OP this looks insane, very broad set of functionality. Im going to run this on my k8s, congratz for now.
• newdee 1y ago
  I’ll be keeping an eye on this, but I’ve gotta say, first glance it just seems like it does way too much, and all by a solo dev in private? Impressive but also perturbing.