What does clientless access actually mean here?

Setting isPublic on a Service makes the Cluster's internet-facing proxy accept requests for that Service's public FQDN and forward them to it after authentication and authorization. A person reaches it in an ordinary browser from any device, including phones and tablets, and a workload reaches it with a standard bearer access token. Nothing is installed on either side.

Which Service modes can be published this way?

The HTTP-based modes: HTTP, WEB, GRPC and KUBERNETES, as well as the MCP and LLM gateway modes and browser-based RDP. For human access to a web application the WEB mode is preferable, because the Service is then presented as a web app with a link straight to its homepage.

How do workloads authenticate without a client?

Through the standard OAuth2 client credentials flow against the Cluster's own token endpoint, or with an access token Credential used directly as a bearer token. Either can be sent in an Authorization: Bearer header or an X-Octelium-Auth header, so ordinary OAuth2 libraries in any language work without a proprietary SDK. Workloads can also authenticate secretlessly with federated OIDC assertions from the platform hosting them.

Do I have to choose between clientless and client-based access?

No. The same Service can be reachable both ways at once, under the same Policies. Client-based access over WireGuard or QUIC tunnels covers protocols a browser cannot speak, such as SSH, PostgreSQL, MySQL and generic TCP and UDP, while clientless access covers the HTTP-based ones from any device.

What is needed to publish a Service to the internet?

A public DNS record and a TLS certificate for the Service's public FQDN, both of which the Cluster manages. Nothing has to be opened towards the upstream itself: an upstream behind NAT is served to the Cluster over a connected client's own outbound tunnel, so no inbound port or firewall rule is added on that side.

Is Octelium free and open source?

Yes. Octelium is free and open source and is designed for single-tenant self-hosting. There is no proprietary cloud-based control plane, and it is not a limited edition of a separate paid product. An enterprise package is available for organizations that need capabilities such as a web console, SCIM provisioning and secret encryption at rest, and it is free for personal, homelab and evaluation use.

Open Source, Self-Hosted BeyondCorp Architecture

The platform

A unified secure access platform

Secure humans, workloads and AI agents with one model for identity, authorization, connectivity, credentials and visibility.

Unified access platform
One architecture for client-based zero-config VPN-like access over WireGuard and QUIC tunnels and clientless access over browsers for humans and OAuth2 access for workloads.
Read more
L7-aware access control
Identity-based, application-layer aware ABAC access control with policy-as-code via CEL and OPA, applied on a per-request basis.
Read more
Secretless access
Dynamic secretless access where teams and AI agents access protected infrastructure without ever holding a credential.
Read more
Unified identity management
Teams, workloads and AI agents share the same model for identity management, access control, and auditing.
Read more
Real-time visibility and auditing
OpenTelemetry-native, real-time, application-layer-aware visibility and structured logging.
Read more
GitOps-friendly management
Octelium is administered like Kubernetes. Define your resources in YAML files, store them in a Git repository.
Read more

Client-based and clientless

One architecture for both ways of reaching a resource

Each resource is protected by an identity-aware proxy that provides application-layer-aware access control, secretless access, and visibility. Clientless access is one field on that Service rather than a separate product.

Read about clientless access

service-private.yaml

A private resourceA resource behind NAT in any environment, with no inbound port opened anywhere.

A private resource. A resource behind NAT in any environment, with no inbound port opened anywhere.

kind: Service
metadata:
  name: wiki
spec:
  mode: HTTP
  config:
    upstream:
      url: http://10.0.6.18:3000

The same resource, clientlessly. Enabling isPublic makes the internet-facing proxy serve the very same Service.

kind: Service
metadata:
  name: wiki
spec:
  mode: HTTP
  isPublic: true
  config:
    upstream:
      url: http://10.0.6.18:3000

A Kubernetes API server. The clientless mode covers HTTP, WEB, GRPC and KUBERNETES Services, not only web apps.

kind: Service
metadata:
  name: prod-k8s
spec:
  mode: KUBERNETES
  isPublic: true
  config:
    upstream:
      url: https://k8s.internal:6443
    kubernetes:
      kubeconfig:
        fromSecret: kubeconfig-prod

Access control

Layer-7 aware access control with policy-as-code

Access is authorized on a per-request basis, using CEL or Open Policy Agent, against the identity behind the request and the content of the request itself rather than the network path it arrived on.

Read about Policies and access control

policy-session.yaml

Session and deviceWhether a request came from a browser, a client or a workload is part of the context.

Session and device. Whether a request came from a browser, a client or a workload is part of the context.

kind: Policy
metadata:
  name: managed-browsers
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.session.status.type == "CLIENTLESS"
            - match: ctx.session.status.isBrowser
            - match: ctx.device.status.osType in ["MAC", "WINDOWS"]

The request itself. Method, path, headers and serialized JSON body are all part of the request context.

kind: Policy
metadata:
  name: api-read-only
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.request.http.method == "GET"
            - match: ctx.request.http.path.startsWith("/v1/")
            - match: '"partners" in ctx.user.spec.groups'

Enforced multi-factor. An Authenticator can be required after sign-in, independently of what the provider enforces.

kind: ClusterConfig
metadata:
  name: cluster-config
spec:
  authenticator:
    authenticationEnforcementRules:
      - condition:
          match: ctx.session.status.isBrowser
        effect: ENFORCE
      - condition:
          match: '"contractors" in ctx.user.spec.groups'
        effect: ENFORCE

Secretless access

Credentials that are never distributed

Application-layer credentials are stored in the Cluster as Secrets and injected into the upstream connection once a request is authorized. The credential the caller presents to the Cluster and the credential the Cluster presents upstream are entirely separate.

Read the secretless access guide

http-auth.yaml

An upstream API keyThe application behind the proxy keeps its own credential, and nobody downstream receives it.

An upstream API key. The application behind the proxy keeps its own credential, and nobody downstream receives it.

kind: Service
metadata:
  name: internal-api
spec:
  mode: HTTP
  isPublic: true
  config:
    upstream:
      url: https://api.internal:8443
    http:
      auth:
        bearer:
          fromSecret: api-key

A SaaS API. Protected public resources are covered too, so a team reaches a SaaS API without holding its key.

kind: Service
metadata:
  name: stripe
spec:
  mode: HTTP
  isPublic: true
  config:
    upstream:
      url: https://api.stripe.com
    http:
      auth:
        bearer:
          fromSecret: stripe-api-key

A different upstream per identity. Identity and request context select which upstream and which credential are used.

kind: Service
metadata:
  name: internal-api
spec:
  mode: HTTP
  isPublic: true
  config:
    upstream:
      url: https://staging.internal
  dynamicConfig:
    configs:
      - name: prod
        upstream:
          url: https://prod.internal
        http:
          auth:
            bearer:
              fromSecret: prod-api-key
    rules:
      - condition:
          match: '"sre" in ctx.user.spec.groups'
        configName: prod

Humans, workloads and AI agents

A unified identity model for humans and workloads

Human and workload Users share the same identity management, authentication, access control and visibility model. The original BeyondCorp problem was people on untrusted devices, and the same architecture now has to carry services and agents as well.

Read about OAuth2 for workloads

idp.yaml

Secretless workload identityWorkloads authenticate with OIDC assertions issued by the platform running them.

Secretless workload identity. Workloads authenticate with OIDC assertions issued by the platform running them.

kind: IdentityProvider
metadata:
  name: github-actions
spec:
  oidcIdentityToken:
    issuerURL: https://token.actions.githubusercontent.com
    audience: https://example.com

A workload User. A microservice reaching a Service is a User with the same groups and Policies as a person.

kind: User
metadata:
  name: microservice1
spec:
  type: WORKLOAD
  groups:
    - services

An MCP gateway. AI agents reach tools clientlessly, through the same identity, Policies and audit trail.

kind: Service
metadata:
  name: tools-mcp
spec:
  mode: MCP
  isPublic: true
  config:
    upstream:
      url: http://mcp.internal:8080
    mcp:
      endpoint: /mcp
      protocol:
        requireVersion: true

Visibility and auditing

Real-time visibility at the application layer

OpenTelemetry-ready, application-layer aware, structured auditing and visibility emitted to your OpenTelemetry OTLP receivers, where they can be exported to your log management and SIEM tools.

Application-layer detail includes HTTP requests and responses, gRPC services and methods, Kubernetes verbs and resources, MCP methods and tool names, and LLM operations and token usage.
Logs are exported over OpenTelemetry OTLP in real-time to SIEM providers you already operate.

Read about visibility and auditing

AccessLogOTLP

ALLOWlinus@acme.compg-prod.dbPOSTGRESquery: select id, email from users limit 50

ALLOWci-runnerprod-k8sKUBERNETESverb=list resource=pods namespace=production

DENYagent-07tools-mcpMCPtools/call name=transfer policy=mcp-tools

ALLOWjane@acme.combastionSSHsession recorded, upstream user=deploy

ALLOWagent-07openaiLLMCHAT_COMPLETIONS model=gpt-5-mini tokens=1284

Deployment and scale

A scalable platform that also deploys your workloads

A Cluster runs on Kubernetes and uses it to scale its own data plane, place Service proxies across Gateways, and run containerized applications that the Cluster itself deploys.

Read the management guide

octeliumctl

❯octeliumctl apply ./cluster

$ octeliumctl apply ./cluster
Secret: api-key Updated
Secret: kubeconfig-prod Updated
IdentityProvider: okta Updated
Policy: browser-access Created
Group: employees Created
Group: services Updated
Service: wiki.internal Created
Service: k8s-dashboard Created
Service: internal-api Created
Namespace: internal Created
Cluster Core resources successfully applied
 7 resources created
 3 resources updated

 ClusterConfig updated

Principles

What a BeyondCorp architecture requires, and what provides it

BeyondCorp is an architecture rather than a product category. These are the properties it is defined by, next to the concrete mechanism in an Octelium Cluster that carries each one.

01
Connecting to a network grants nothing
There is no privileged network to be on. A request is authorized against the identity behind it and the request itself, whether it arrives from an office, a home connection or a mobile network, and whether it came over a tunnel or straight from a browser.
Read more
02
Applications are reached through an access proxy
Each protected resource is represented by a Service served by an identity-aware proxy, which terminates the request, authenticates it, authorizes it and only then reaches the upstream. The upstream is never directly exposed to the internet.
Read more
03
Every resource is protected individually
Publishing one Service does not publish anything else. Each has its own public FQDN, its own Policies and its own upstream credential, so an authorization mistake is scoped to a single resource rather than to a network segment.
Read more
04
People sign in with the identity they already have
Human Users authenticate through any OpenID Connect or SAML 2.0 identity provider, or GitHub OAuth2, in an ordinary browser flow. Group membership from that provider is what Policies are written against.
Read more
05
Device state is part of the decision
Device information is available in the request context and combines with identity, group membership, session type and time in the same policy expression, so an unmanaged device can be allowed to reach some resources and not others.
Read more
06
The strength of the authentication can be raised
Native FIDO2 and WebAuthn passkeys, TOTP and TPM 2.0 authenticators can be required after a sign-in through enforcement rules, independently of what the identity provider itself enforces.
Read more
07
Non-human clients are covered by the same model
Workload Users reach the same clientless Services with the standard OAuth2 client credentials flow or bearer access tokens, using ordinary OAuth2 libraries in any language, with no client and no proprietary SDK.
Read more
08
Every access is recorded with its identity
Each request produces an identity-aware, application-layer AccessLog naming the User, Session and Device, streamed in real time over OpenTelemetry to your own log management and SIEM providers.
Read more

Putting a login page in front of an application is not a BeyondCorp architecture on its own. What makes it one is that the decision is made per request, from identity and device state, by a proxy the resource sits behind rather than beside.

On every Octelium Cluster

The same platform capabilities ship with every deployment, whichever way you use it.

Questions

Frequently asked

What does clientless access actually mean here?: Setting isPublic on a Service makes the Cluster's internet-facing proxy accept requests for that Service's public FQDN and forward them to it after authentication and authorization. A person reaches it in an ordinary browser from any device, including phones and tablets, and a workload reaches it with a standard bearer access token. Nothing is installed on either side.
Which Service modes can be published this way?: The HTTP-based modes: HTTP, WEB, GRPC and KUBERNETES, as well as the MCP and LLM gateway modes and browser-based RDP. For human access to a web application the WEB mode is preferable, because the Service is then presented as a web app with a link straight to its homepage.
How do workloads authenticate without a client?: Through the standard OAuth2 client credentials flow against the Cluster's own token endpoint, or with an access token Credential used directly as a bearer token. Either can be sent in an Authorization: Bearer header or an X-Octelium-Auth header, so ordinary OAuth2 libraries in any language work without a proprietary SDK. Workloads can also authenticate secretlessly with federated OIDC assertions from the platform hosting them.
Do I have to choose between clientless and client-based access?: No. The same Service can be reachable both ways at once, under the same Policies. Client-based access over WireGuard or QUIC tunnels covers protocols a browser cannot speak, such as SSH, PostgreSQL, MySQL and generic TCP and UDP, while clientless access covers the HTTP-based ones from any device.
What is needed to publish a Service to the internet?: A public DNS record and a TLS certificate for the Service's public FQDN, both of which the Cluster manages. Nothing has to be opened towards the upstream itself: an upstream behind NAT is served to the Cluster over a connected client's own outbound tunnel, so no inbound port or firewall rule is added on that side.
Is Octelium free and open source?: Yes. Octelium is free and open source and is designed for single-tenant self-hosting. There is no proprietary cloud-based control plane, and it is not a limited edition of a separate paid product. An enterprise package is available for organizations that need capabilities such as a web console, SCIM provisioning and secret encryption at rest, and it is free for personal, homelab and evaluation use.

Keep reading

Deploy Octelium on your own infrastructure in minutes

Free and open source. Self-hosted. No vendor lock-in.

Quick install guide GitHub repo Enterprise package

An open source, self-hosted BeyondCorp architecture

A unified secure access platform

One architecture for both ways of reaching a resource

Layer-7 aware access control with policy-as-code

Credentials that are never distributed

A unified identity model for humans and workloads

Real-time visibility at the application layer

A scalable platform that also deploys your workloads

What a BeyondCorp architecture requires, and what provides it

Connecting to a network grants nothing

Applications are reached through an access proxy

Every resource is protected individually

People sign in with the identity they already have

Device state is part of the decision

The strength of the authentication can be raised

Non-human clients are covered by the same model

Every access is recorded with its identity

Frequently asked

Related solutions

Zero Trust Network Access

Cloudflare Access alternative

Zero trust SaaS and API access

Deploy Octelium on your own infrastructure in minutes