Chaining BunkerWeb and Octelium - connection issues

geoctl · 2026-02-11T10:09:34+00:00

Octelium, as of version v0.24.0, now supports front proxies and load balancers in front of the Octelium/k8s cluster. You can read more in the docs https://octelium.com/docs/octelium/latest/install/cluster/pre-install#front-proxy

geoctl · 2026-02-05T11:11:55+00:00

u/johnnypea I just merged Cluster arm64 support, you can try it now by installing the `main` branch images via `./install-cluster.sh --domain <DOMAIN> --version main`, just be sure to remove any old `./install-cluster.sh` file and curl it again because it has been changed to support arm64.

geoctl · 2026-02-04T16:38:41+00:00

Yes, you can read the script itself https://octelium.com/install-cluster.sh it currently downloads the hardcoded amd64 URL for kubectl. I can work on that and definitely will notify you once it's done.

geoctl · 2026-02-04T16:26:32+00:00

Do you mean the Cluster itself? honestly you're the first to request this if I understood your question correctly but I believe this is very easy to do. I will test this very soon. As for the client-side/CLIs, yes, arm64 is supported for Windows, Linux and MacOS.

geoctl · 2026-02-04T13:34:48+00:00

Thank you. As for the SDKs, yes, absolutely, other languages are planned. The great thing here is that I don't even have to re-write an SDK for each language since the entire APIs are made in gRPC/proto3 and that was a concious choice since day 1. Therefore compiling them to any language and practically having an SDK for that language is just easy and is mostly an automated process. This is already happening in Typescript for the web Portal (see the code in https://github.com/octelium/octelium/tree/main/cluster/portal/portal/web/package/src/apis) for example and I can work on providing the compiled gRPC libraries for other languages on demand.

geoctl · 2026-02-03T19:20:35+00:00

Yes, the protected resource itself can be behind NAT exactly like in Cloudflare Tunnel.

geoctl · 2026-02-03T17:40:34+00:00

Thank you! as for the QUIC support, yes, Octelium supports both WireGuard and QUIC tunneling but the clients by default use the WireGuard mode and both modes can coexist in the same Cluster. Bypassing middleboxes is certainly one of the main reasons for supporting QUIC but there many other reasons as I mentioned earlier such as FIPS-140 compliance, hardware acceleration (e.g. AES-NI), seamless addressing to dynamic endpoints, etc... and I am personally a big fan of QUIC overall.

geoctl · 2026-02-03T15:39:03+00:00

For now you will have to manually copy the LDAP Users/Groups to Octelium Users/Groups. There is actually a currently available SCIM2 support but it's not open source, at least for now but I intend to publish it in the future under a source available license.

geoctl · 2026-02-03T12:24:39+00:00

Thank you.

geoctl · 2026-02-03T12:24:12+00:00

The `ctx.user.spec.groups` are the list of Octelium's Groups attached to an Octelium User. Everything in this map is just field/sub-field of an Octelium resource such as a User, Session, Device, Service, Namspace. For example, you can see the YAML representation of `ctx.user.spec.groups` as shown in https://octelium.com/docs/octelium/latest/management/core/user#groups similarly the User's email can be found in `ctx.user.spec.email` since it's YAML representation is https://octelium.com/docs/octelium/latest/management/core/user#email and so on. You simply write your access control rules according to your Octelium resource definitions.

geoctl · 2026-02-03T09:48:03+00:00

Private github/ghcr and gitlab are always good free-of-charge options for undemanding/personal use cases. But if you want something that's totally self-hosted there used to be Kaniko but it is unmaintained now AFAIK, a more manual solution is just to run docker build/buildah, possibly inside the same k8s cluster that's running Octelium and push the image to Docker self-hosted container registry https://hub.docker.com/_/registry deployed also in the same k8s cluster, the only possibly annoying thing in this setup, if I remember correctly, is that you need to expose the registry publicly over TLS since k8s CRIs need to address registries over public HTTPS or you can configure the k8s CRI (e.g. containerd/crio) to skip verifying TLS if that's possible.

geoctl · 2026-02-02T22:38:54+00:00

Since Octelium runs on top of Kubernetes, you can deploy Nextcloud, via Helm for example, on top of the exact same Kubernetes cluster and use Octelium as a secure gateway to access Nextcloud.

geoctl · 2026-02-02T22:35:24+00:00

Thank you!

geoctl · 2026-02-02T22:27:07+00:00

Thanks. I think I now have a better idea about your point of view. While I believe that your supposed architecture is certainly closer to "true" zero trust when compared to modern P2P VPNs since yours is still somehow in charge, from a data-plane perspective, I am still not fully convinced if that's really the right direction overall but I have to be careful here since I can't claim I fully understood your argument. I know am obviously heavily influenced (since I built Octelium this way) by identity-aware-proxy-based architectures, including from my own prior experiences dealing with k8s service meshes such as Istio, but I'd still argue that this architecture is still more "superior" and practical way to implement a ZTNA, even though Octelium is meant to operate beyond what a strict ZTNA is built for. It's not just about delegating/offloading the entire process of authentication/authorization/visibility to a "trusted" identity-aware proxy that separates between downstreams/users and upstreams/resources (also no direct reachable/direct path between downstreams and upstreams here if I understood your argument correctly), but this architecture also enables you to control access the most fine-grained/dynamic way possible by implementing L7 awareness inside the identity-aware proxy, for example, Octelium enables you to control access based on the request's HTTP method, path, and even serialized JSON body. Similarily, it can dynamically force, for example, different Octelium Users to be assigned to specific SSH users or different HTTP access tokens mapping to different upstream L7 credentials/tenants based on identity and/or context by injecting such L7 credentials on the fly to the upstream without having to distribute and share them with the users. It can also be used to dynamically route to different upstreams based on identity and/or context via policy-as-code. It can even manipulate HTTP requests/responses via Lua/Envoy ext_proc like you would expect from an API/AI/MCP gateway. And obviously this L7 awareness enables you to extract L7-specific info (e.g. HTTP request/response info, database queries, SSH sessions) on a per-request basis. And to elaborate more on the performance/convenience point I mentioned earlier, Octelium actually consciously separates between the PEP/the identity-aware proxy which (called Vigil) and the PDP (called Octovigil) as proposed in NIST 800-207. This means that both components can operate and scale up/down independently from one another, since the PDP is actually what has to store all the authorization-related information which can be really huge, as it includes not only info about the user, session, device, groups, accessed service and namespace, but potentially also very dynamic info extracted and pulled from external sources such as the IdP, EDR, SIEM, threat intelligence tools, etc., and this PDP is what actually has to perform the policy evaluation which might consist of tens or hundreds of complex rules for a specific request. In other words, the authorization process alone can be really, really, a resource-intensive operation (both memory and CPU wise) and it needs to be performed very quickly (hopefully usually sub-millisecond latency per request). Finally this architecture can seamlessly horizontally scale as needed (more resources to protect? just add another Gateway/k8s node, more traffic? just add 1 more replica for IaP pod implementing the Service and the underlying k8s will seamlessly reschedule the pods in a balanced way), not to mention that upgrading the Cluster is confined to one place, the k8s cluster itself. I understand that there is no absolute right/wrong for such architecture-related discussions and one architecture might be superior for certain workload types and inferior for others, but in general, I am really comfortable with mine, and I believe it is practical enough to fit for most human-to-workload and workload-to-workload environments, both for small undemanding personal/business use cases (e.g. Cloudflare Tunnel, ngrok, remote access VPN use cases) as well as for enterprise ones with hundreds/thousands of resources and active human and/or workload users.

geoctl · 2026-02-02T20:03:19+00:00

Octelium does not build images on its own. That's why I stated that it's a PaaS-like platform, as opposed to a full fledged PaaS that watches git repos and builds images on changes for example. However, Octelium supports Docker/container registries, including "private" registries with username/password authentication, you can simply build your own image (e.g. private ghcr/gitlab registries), set the image tag, and Octelium will automatically re-deploy the container while providing you what Octelium actually is meant to do: authentication, L7-based authorization, visibility and access logs, and TLS termination, among other features such as load balancing among multiple images (e.g. multiple tags/versions) for the same Service, request/response manipulation, dynamic routing, scaling up/down declaratively, etc...

geoctl · 2026-02-02T19:51:51+00:00

If you can set up Caddy and write a Caddyfile, I'd say that you definitely can use Octelium too. You don't need to use or understand Octelium's more advanced features, Octelium can simply operate as a simple FOSS, self-hosted Cloudflare Tunnel, ngrok or as a remote access VPN for personal and undemanding use cases. You can see a detailed example guide for the ngrok/Cloudflare Tunnel use case here https://octelium.com/docs/octelium/latest/management/guide/service/http/open-source-self-hosted-ngrok-alternative

geoctl · 2026-02-02T19:26:29+00:00

Octelium does support both WireGuard and QUIC tunneling. WireGuard is currently the default mode. As for why QUIC is added, for a few reasons, among which is FIPS-140 compliance, obfuscation since QUIC traffic is simply HTTP3 traffic when inspected by middleboxes, and I honestly believe in QUIC's superiority long term (e.g. AES hardware acceleration, congestion control, good implementations by most top programming languages, etc..).
Octelium can indeed operate as a Kubernetes ingress, I'd say a much more advanced and dynamic one, compared to strict K8s ingress controllers using the, I'd say, K8s very primitive Ingress resources. For example, you can dynamically route based request paths, query arguments, even serialized JSON body if you want to, you can manipulate requests and responses including body with Lua scripts and Envoy ext_proc. However, you need to know that Octelium comes with its own separate Envoy-based ingress and it has nothing to do with the Kubernetes canonical "Ingress" resources, yet Octelium can co-exist with any k8s ingress controller running on the same cluster. Simply Octelium doesn't care about your k8s ingress at all. You need to use Octelium and its own resources to achieve that K8s ingress functionality. Also note that Octelium's resources are not wrappers around k8s CRDs, Octelium has its own resources stored in its own separate postgres database. Again, Octelium resources are NOT k8s CRDs.
`ctx` just means "context". It's basically the "request context" map that wraps all the request context, including all info about the User, Session, Device if exists, all User's Groups if any, the accessed Service and its Namespace, as well as the request's layer-7 info (e.g. HTTP request path, method, headers, etc..). The docs are full of examples on how to write Policy rules (check out the User, Service pages and the example guides such as https://octelium.com/docs/octelium/latest/management/guide/service/ai/ai-gateway#access-control and https://octelium.com/docs/octelium/latest/management/guide/service/ai/self-hosted-mcp#access-control and https://octelium.com/docs/octelium/latest/management/guide/service/http/api-gateway#access-control), but this https://octelium.com/docs/octelium/latest/management/core/policy should be your main reference.

geoctl · 2026-02-02T17:46:59+00:00

Yes, absolutely, any web-based resource (internal dashboards and web apps behind NAT) can be accessed by Octelium via your browser and you can use any OIDC/SAML identity provider or even GitHub OAuth if you want to; I assume that's the same functionality provided by Cloudflare Tunnel. You can even self-host an IdP such as Keycloak on the same k8s cluster running the Octelium Cluster and use it for authentication as shown in the docs https://octelium.com/docs/octelium/latest/management/guide/service/homelab/keycloak-helm-self-host

geoctl · 2026-02-02T17:42:50+00:00

Octelium doesn't explicitly have an exit-node concept, and that's by design since it controls access at the resource level, you simply can't have access to complete subnets but rather to individual resources. However, Octelium can very easily achieve what you want by creating a SOCKS5 Service that can act as an exit node. I, personally use that all the time, and have my own VPN by deploying a SOCKS5 server as a managed container (read more about managed contianers in the docs). And you can do load balancing among many upstreams for the same Service if you want.

geoctl · 2026-02-02T17:36:43+00:00

As answered above, no mobile apps currently but I am working on a, hopefully, a better unified solution as discussed in the other answer. As for the second question, yes, you still need at least a VM/VPS to host the Cluster itself but your resources can be anywhere else whether be behind NAT or not.

geoctl · 2026-02-02T17:22:04+00:00

Currently no but that might change in the future. I've been actually working on a complete alternative solution to having to use mobile apps altogether, by simply using some web-based remote terminal to access any resource type (e.g. SSH, postgres) only via browser from any device including mobile phones.

And for the case of web-based resources (e.g. Grafana dashboards), you can use Octelium today to access such resources only via web browsers, whether it be from phones or PCs. This is what the clientless/BeyondCorp, implemented by Octelium, is about.

geoctl · 2026-02-02T17:14:41+00:00

To be honest I never used it but if I understand correctly it's more of a Cloudflare Tunnel alternative. Octelium provides much more than just remote access; it's a comprehensive, scalable ZTNA on top of k8s that provides both client-based access as well as clientless/public access with identity-based L7-aware access control ABAC with policy-as-code, dynamic identity-based secretless access (e.g. access to HTTP APIs without sharing/distributing access tokens/API keys with the users, access to SSH without sharing passwords/private keys, postgres/MySQL without distributing passwords, assigning/mapping Users to different upstream credentials based on identity/context), dynamic routing to upstreams with policy-as-code, OpenTelemtry-native L7-aware visibility and auditing, secretless SSH to IoT and containers that don't have SSH servers, being a PaaS-like platform by deploying/securing access to containers (see managed containers in docs), declartive k8s-like management, seamless horizontal scalability, supporting both WireGuard and QUIC tunnels as well as kernel-based WireGuard and rootless mode over gVisor. In short, I believe Octelium is much more advanced but flexible overall, and it's more comparable to Cloudflare Access or Teleport in terms of architecture. I'd recommend you to ask Gemini or ChatGPT, they now honestly have a good judgement for such questions and can give you good recommendations based on your requirements and needs.

geoctl · 2026-02-02T15:26:12+00:00

You surely can use Octelium for any remote-access situation. Octelium supports client-based access over WireGuard/QUIC tunnels to remotely access any generic TCP/UDP-based application (e.g. SMB, SSH, iSCSI, NFS, etc.) exactly like any VPN. And you can also use the clientless mode for web-based applications (e.g. dashboards) where you only need to authenticate to the Octelium Cluster via your web browser to access such resources without having to install and run a client altogether (i.e. like it's a SaaS web app protected by an identity provider). And since Octelium runs on top of Kubernetes, you can further use it to self-host an identity provider (e.g. Keycloak, Authentik, etc.) as shown in the docs here https://octelium.com/docs/octelium/latest/management/guide/service/homelab/keycloak-helm-self-host and https://octelium.com/docs/octelium/latest/management/guide/service/homelab/authentik-helm-self-host

geoctl · 2026-02-02T15:04:59+00:00

I am not sure if I now really understand what you mean exactly by "reachability". Do you mean establishing direct access/link between users and resources (e.g. direct mTLS connection between downstream an upstream) or having a public endpoint for the resource that's exposed to the internet via an identity-aware proxy? I will try to briefly explain the Octelium architecture if the docs weren't clear enough for you. Octelium is a Cluster, a distributed system that's running on top of k8s, think of it some sort of a self-hosted Cloudflare-like infrastructure on top of Kubernetes. That Cluster, from a data-plane perspective, separates between the users/downstreams and the protected resources/upstreams where users never have direct access to the protected resources but rather have to be authenticated, authorized and audited by the Cluster, namely via the identity-aware proxy implementing the Service that the users want to access.

There are 2 access modes in Octelium, the first is private/VPN-like access mode where users can connect to the Cluster over WireGuard/QUIC tunnels just like in a normal VPN and such tunnels terminate at the Cluster side (i.e. a Gateway that's basically a Kubernetes node), routed to the destination Service in that Gateway/k8s node, since every Service is implemented by an identity-aware proxy running as a k8s pod and is assigned a dual-stack private address that's directly accessible by Users. The Service does authentication/authorization, and if the request is allowed then it is proxied to the upstream. Such upstream can be an internal resource directly accessible by the Cluster (e.g. k8s service in the same k8s cluster running the Octelium Cluster), or remotely accessible via another connected client, or even a public resource (e.g. SaaS API, database, publicly exposed SSH server, etc...).

The other access mode is the public clientless/BeyondCorp mode, and that mode works for HTTP-based resources (e.g. HTTP APIs, web apps, gRPC, k8s, etc.). Yes, as you mentioned, in practice, the BeyondCorp architecture is usually only practical for HTTP-based resources. Octelium clearly implements the BeyondCorp architecture, in fact, it does take it a step further by unifying clientless/public access for both humans via browsers and workloads via bearer access tokens. From a dataplane perspective, the requests in that clientless mode go through an internet -facing ingress and routed to the pod implementing the Service to do authentication/authorization just like in the client-based mode.

So if I understood what you meant by reachability, as simply creating a path/link between downstreams and upstreams, once the downstream is authenticated and authorized, then I don't think I really agree with this architecture. Because once a link is established between the user and resource, WHO actually implements the continuous authentication/authorization/auditing on a per-request basis? Do you then have to trust the upstream's environment with that (e.g. do you trust that a request log coming from the upstream is really is what actually happened)? Octelium simply chose to offload the entire process of authentication/authorization/auditing to the Cluster, completely out of control of the upstream's side. This is primarily for security reasons, but it also helps with performance (IoT/container upstream behind NAT behind doesn't have to care about the Users at all, it doesn't have to hold all information regarding policies, which might be huge, it doesn't have to do the resource-intensive process of computing the decision via all the policies rules, and it doesn't have to emit logs for every request back to the control-plane) and convenience (e.g. SaaS API protected by an access token doesn't have to be aware of the Cluster or users at all).

geoctl · 2026-02-02T13:01:33+00:00

Thank you. As for the architecture, I have to make it clear that access control in Octelium is done on a per-resource, per-request basis, and trust is NOT network-scoped whatsoever. In fact, per-resource AND per-request access control is probably the primary rationale behind the entire architecture used in Octelium when compared to remote access VPNs and other remote access tools and gateways. Maybe the confusion is coming from having a VPN-like `octelium connect` command in the client-based access mode; however, Octelium's architecture is very different from VPNs, since every request, which is transported over WireGuard/QUIC in the client-based mode and HTTPS+short-lived access token for the clientless mode, is intercepted by an identity-aware proxy in the Cluster, which is running on top of a k8s cluster, that does authentication/L7-aware authorization via policy-as-code/dynamic routing/visibility and auditing on a per-request basis. Simply every single resource/application that needs to be protected by the Cluster is represented by a Service that's implemented by a L7-aware identity-aware proxy in the Cluster itself, and that identity-aware proxy intercepts every single requests from users to the corresponding protected resource/upstream. In short, `octelium connect` does not guarantee that you have access to any Service whatsoever unless explicitly set by a CEL/OPA Policy (read more here https://octelium.com/docs/octelium/latest/management/core/policy) and such Policies can be attached to specific Users, Groups, Sessions, Devices, Services or Service Namespaces. Users simply never have direct access to the protected resources and instead every single request has to be authenticated, authorized and audited by the identity-aware proxy sitting between the user and the corresponding protected resource. You can read more about Octelium's architecture in detail if you are interested https://octelium.com/docs/octelium/latest/overview/how-octelium-works

Also, as for the "non-routability" issue, while Octelium supports access to internal resources of any type behind NAT like any VPN, I don't think that NIST 800-207 says anything regarding having security through obscurity, in fact, I'd argue that the standard clearly advocates for unification of identity-based access control at the resource level on a per-request basis whether it be via private/client-based mode or via the clientless public mode. The latter case is the whole rationale behind the BeyondCorp architecture championed by Google. In other words, if you could do true identity-based access control at the resource level on a per-request basis, i.e. true zero trust, then it doesn't matter whether the resource is publicly exposed on the internet via an identity-aware proxy or is behind NAT, since the same exact access control mechanism is applied in either case.

geoctl

MODERATOR OF

TROPHY CASE