HN Explorer

Show HN: Octelium – FOSS Alternative to Teleport, Cloudflare, Tailscale, Ngrok (github.com)

358 points by geoctl ↗ HN
I have been working on Octelium for quite a few years now but it was open sourced only by late May 2025. 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. It can operate as a remote access/corporate VPN (i.e. alternative to Twingate, Tailscale, OpenVPN Access Server, etc...), a ZTNA/BeyondCorp platform (i.e. alterntive to Cloudflare Access, Teleport, Google BeyondCorp, etc...), and it can also operate as an API/AI gateway, an infrastructure for MCP and A2A architectures and meshes, an ngrok alternative, a homelab infrastructure or even as a more advanced Kubernetes ingress. It's basically designed to operate like a unified Kubernetes-like scalable architecture for zero trust secure/remote access that's suitable for different human-to-workload and workload-to-workload environments. You can read more in detail the full set of main features and links about how it works in the repo's README or directly in the docs https://octelium.com/docs

59 comments

[ 3.8 ms ] story [ 71.3 ms ] thread
kosolam
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
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.
yjftsjthsd-h
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
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.
ethan_smith
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.
mzhaase
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
I'd appreciate if you could provide me a list of those buzzwords so that I can improve the readme.
[deleted]
(comment deleted)
rollcat
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>

geoctl
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/s... As for the 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/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
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/

geoctl
Thank you. I will definitely work on making the README more concise and hopefully more useful and easy to understand.
ar-nelson
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-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
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.
cedws
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.

therealpygon
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
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.
csomar
Give open source devs a break. We don't know the OP background or his motivations. He might have been working on this for fun. He doesn't need to justify any of this. This is open source and Free software. Take it as it is.

> If a software is hard to explain the purpose of to an average person in a single sentence, you have an uphill battle.

It does. If you use tailscale/cloudflare access and ngrok, the product is pretty well described. If you don't, then probably you don't need this product.

canada_dry
> solo dev/no name company is going to suddenly drop a product

A developer/company with an opaque background that you're to trust to give access to backend systems using passwordless embedded SSH (no keys needed!).

That's a big NOPE.

(Also, even the answers OP has provided really give an AI bot vibe)

pydry
Can you use VPNs outside of your infra (e.g. protonvpn, mullvad) as an exit node?
geoctl
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.
shrubble
One takeaway is that this can replace ZLayer, and it does offer much more functionality than that. Is that correct?
Onavo
How does it compare to Pangolin?
geoctl
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
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.
kevmo314
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.

b0a04gl
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
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/s... https://octelium.com/docs/octelium/latest/management/guide/s... https://octelium.com/docs/octelium/latest/management/guide/s... https://octelium.com/docs/octelium/latest/management/guide/s...

wkat4242
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.

geoctl
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".
metmac
Reading through the docs. I feel like a lot of people are missing the value here. This could be a diamond in the rough if it actually delivers on its docs.

What enterprises want is to move away from perimeter based security models towards the promise that Google überProxy/BeyondCorp popularized many years ago. Which has been lost in the buzzword soup. It’s very simple.

1. A clean separation between Prod, Corp, and the public internet. And the UX to hop between them as an employee is as transparent as possible. (Often times network segmentation comes with additional painful friction for engineerings.)

2. One pipe to observe, and clearly attenuate permissions as traffic/messages flows between these boundaries.

3. Strong proofing of identity for every client, as an inherit requirement.

The problem is everyone outside Google has incredibly diverse protocol ecosystems. It makes those three promises incredibly difficult to deliver on as a vendor. (I’ve evaluated many)

To build a proxy that is protocol aware, only solves half the problem. It gets you some coarse grain decision making and a good logging story.

To build a proxy that is also able to perform type-inference at the request layer, allows for a much richer authZ story. One where businesses can build an authorization layer at the proxy better than their in-house apps could even do natively. (As it turns out, having all the predicates of the request available to a policy engine is super useful).

The docs are a little verbose, the marketing maybe isn’t amazing. But this is inherently a complex problem. No one has fully solved.

Teleport was first to the market to OSS and commercialize a lot of these ideas. StrongDM also is doing really interesting work in this space. I wish Hashicorp had invested more in this space.

Disclaimer: my opinions are my own.

jvink
Look into sanctum [1] it's cathedral mode. You can self-host those entirely and they're only discovery nodes. Once the tunnel is up the cathedral isn't involved unless for black key distribution or if your peers are behind restrictive NAT.

There's reliquary [2] which I host and run for me and my hacker friends based on sanctum.

[1] https://github.com/jorisvink/sanctum

[2] https://reliquary.se

[deleted]
(comment deleted)
Arch-TK
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
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
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
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
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
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
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
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.

udev4096
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
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
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
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 ser...

geoctl
Thank you really for your detailed comment. I will try to answer your questions and please don't hesitate to ask in the Slack/Discord channels or contact emails later if the answers here weren't clear enough to you.

1. Octelium Services and Namespaces are not really related or tied to Kubernetes services and namespaces. Octelium resources in general are defined in protobuf3 and compiled to Golang types, and they are stored as serialized JSON in the Postgres main data store simply as JSONB. That said, Octelium Services in specific are actually deployed on the underlying k8s cluster as k8s services/deployments. Octelium resources visually look like k8s resouces (i.e. they both have the same metadata, spec, status structure), however Octelium resources are completely independent of the underlying k8s cluster; they aren't some k8s CRDs as you might initially guess. Also Octelium has its own API server which do some kind of REST-y gRPC-based operations for the different Octelium resources to the Postgres via an intermediate component called the rscServer. As I said, Octelium and k8s resources are completely separate regardless of the visual YAML resemblance. As for managed containers, you don't really have to use it, it's an optional feature, you can deploy your own k8s services via kubectl/helm and use their hostnames as upstreams for Octelium Services to be protected like any other upstream. Managed containers are meant to automate the entire process of spinning up containers/scaling up and down and eventually cleaning up the underlying k8s pods and deployments once you're done with the owner Octelium Service.

2. Secret management in Octelium is by default stored in plaintext. That's a conscious and deliberate decision as declared in the docs because there isn't any one standard way to encrypt Secrets at rest. Mainline Kubernetes itself does exactly the same and provides a gRPC interface for interceptors to implement their own secret management (e.g. HashiCorp Vault, AWS KMS/GCP/Azure offerings, directly to software/hardware-based HSMs, some vault/secret management vendor that I've never heard of, etc...). There is simply no one way to do that, every company has its own regulatory rules, vendors and standards when it comes to secret management at rest. I provided a similar gRPC interface for everybody to intercept such REST operations and implement their own secret management according to their own needs and requirements.

3. Octelium has Session resources https://octelium.com/docs/octelium/latest/management/core/se... Every User can have one or more Sessions, where every Session is represented by an opaque JWT-like access token, which are used internally by the octelium/octeliumctl clients after a successful login, they are also set as a HTTPOnly cookies for BeyondCorp browser-based Sessions and they are used directly as bearer tokens by WORKLOAD Users for client-less access to HTTP-based resources. You can actually set different permissions to different Users and also set different permissions for different Sessions for the exact same User via the owner Credentials or even via your Policies. OAuth2 client credential flow is only intended for WORKLOAD Users. Human Users don't really use OAuth2 client credentials at all. They just login via OIDC/SAML via the web Portal or manually via issued authentication token which is not generally recommended for HUMAN Users. OAuth2 is meant for WORKLOAD Users to securely access HTTP-based Services without using any clients or SDKs. OAuth2 scopes are not really related to zero trust at all as mentioned in the docs. OAuth2 scopes are just an additional way for applications to further restrict their own permissions, not add new ones which are already set by your own Policies.

4. An Octelium Cluster runs on to...

marifjeren
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
OP this looks insane, very broad set of functionality.

Im going to run this on my k8s, congratz for now.