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.
Believe me I am the one who's actually still struggling to find where the jargon/buzzwords/naming dropping exactly is in my own README. Is it terms such as ZTNA/BeyondCorp, MCP, A2A, AI/API gateway? Is it secretless access, zero trust? I will do my best to simplify the README and docs. It's not like I am happy that even technical people are struggling to quickly understand the README. I admit that there must be something wrong with the README/docs and I am going to improve it. All those people hinting the same thing cannot just be wrong.
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-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.
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.
Thank you, I will definitely add more kind of less-technical information on the homepage to make it easier to understand for business people. As for comparisons, I have been actually reluctant to do it because I don't think I can ever do a truly neutral comparison myself and I believe it should come from neutral parties such as blogs as well as users trying to discover the best solution that works for their own use case. But since I have been asked multiple times already I will probably add some comparisons soon.
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...
Thank you really for your comment. I was actually hoping myself to get more questions that are related to the internals and architecture of Octelium, especially from those who are familiar with commercial ZTAs such as Cloudflare Access, Teleport, StrongDM, Google BeyondCorp, Pomerium and many other ZTNA/BeyondCorp based solutions.
Thank you. Honestly if I had the right to give you my opinion, I'd just advise you to go back to full custom Go-based proxies regardless of how overwhelming that might sound. Octelium itself still does use Envoy as an ingress for the BeyondCorp mode to route to the intended Service based on the FQDN, however, Envoy as great as it is for ingress and HTTP-based service mesh purposes especially when it comes to memory/CPU usage under huge load conditions, it really shows weakness when it comes to building generic multi L7-protocol aware (e.g. HTTP, SSH, Postgres, MySQL, RDP, etc...) IaPs where you need to understand L7 for each of these protocols to provide access control, modifications to the protocol specific messages and providing L7 aware visibility. The amount of work you need to do in ext_proc, ext_authz, proxy-wasm, etc... is just ridiculous and error prone due to the extra round trips yet it is equivalent to what you could have done if you owned the entire data plane yourself.
I apologize if my reply was seen as critical in any way. I only wanted to make a difference between Octelium as a complete platform compared to Pomerium (I meant the open source project not the entire Enterprise offering which is obviously a complete BeyondCorp solution) and Ory Oathkeeper as identity-aware proxies. A more technical description for Octelium is that it is for IaPs similar to what Kubernetes is for containers. It simply provides a complete control plane to manage and deploy IaPs on top of Kubernetes itself. In fact, I am a fan of Pomerium and their work (I still remember your great work related to Golang's Webauthn and its attestation-related stuff ~3 years ago) if you're part of the team. Funnily enough, Octelium started as a sidecar ext_authz svc for Envoy instances to operate as an IaP but I ended up creating my own Golang-based IaP, Vigil, from scratch because Envoy was just nothing but pain outside HTTP-based resources.
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".
I completely agree with you. And tbqh since almost everybody in the thread is complaining about the README then I must be really doing something wrong explaining Octelium and what it does. I will certainly put more effort to make the README and especially the main description section more useful and easier to understand without transforming it into more of a marketing pitch. As I mentioned in other replies, it's actually really hard to concisely describe fairly complex projects (e.g. Kubernetes, Istio, etc...), especially to newcomers. But I will definitely do my best to improve the docs and README. Thank you really for your insightful comments.
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:
Thank you. I think your description is great but I, as a user myself, might see it as an identity-aware proxy (i.e. something like Pomerium and Ory Oathkeeper IaPs which are great projects) as opposed to a complete Kubernetes-tier platform that does the entire process of remote access, access control, visibility and auditing, user and identtiy management, centralized policy management, etc... from a data-plane and control-plane perspective for an arbitrary number of resources that need to be protected.
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.
Thank you. I completely understand your point of view. I did put a lot of effort actually trying to come up with a simple concise description that can fit in an HN 80-char wide title but I simply could not do it. If you think about it, other fairly complex projects such as Kubernetes or Istio are also very hard to concisely describe for newcomers. There is always some assumption that potential users of the project are already acquainted with the terms used in modern zero trust architectures and familiar with similar commercial products such as Cloudflare Access, Teleport, StrongDM and many other related products.
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".
I have been developing the project solo on a private GitHub repo since 2020. I am not VC-backed or whatever else, Octelium has been a solo effort so far basically. The project itself is now 100% open source as you can see. However, even if I open sourced the initial private repo, what would make you believe that I am who I really am? maybe even all those git commits from 2020 weren't really from 2020 and their timestamps have been spoofed to make you believe so. If 100% of the codebase of the project being open source is still not enough, I guess nothing can be enough.
I am sorry that you find whatever I say as nothing but "jargon". I assume that those interested in Octelium are already interested in zero trust architectures as defined by NIST, simply products such as Cloudlfare Access, Teleport, StrongDM, Google BeyondCorp, Zscaler ZTNA, etc... I will do my best to simplify the README soon.
Thank you. Octelium, however, does not operate as p2p and does not directly connect devices since that by itself contradicts the whole point of zero trust. It provides remote access to resources, or even sub-resources via L7 access control (e.g. allow access to some HTTP paths to some users based on identity/context/request content, etc...), not completely to "devices" or to complete subnets.
Thank you. I completely understand your point. But as mentioned in the other replies. Octelium is designed to be much more than just a VPN. It is not even tied to provide remote access to "devices" or resources behind NAT. It's zero trust architecture that's equally designed to provide access to internal resources and publicly protected resources such as SaaS APIs, databases, Kubernetes APIservers, SSH, etc... It provides both client-based (i.e. VPN-like) access as well as clientless access for both humans and workloads. For example, Humans can just use their browsers to access internal resources behind NAT like a typical protected SaaS resource. Workloads written in any programming language can access protected HTTP/gRPC APIs, Kubernetes, etc... via standard OAuth2 and bearer authentication without using any clients or special SDKs even such protected resources are protected by different API keys/access tokens.
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.
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.
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.
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.
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/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.
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.