BeyondCorp is a zero trust networking architecture that allows users, typically human users, to access protected resources in a clientless way via an internet-facing identity-aware proxy. The major advantage of BeyondCorp is that it allows human users to access the protected resources, specifically web-based applications, directly using their browsers just like a typical SaaS application without having to install and use an agent/client on their end.

Octelium currently supports the clientless BeyondCorp mode for HTTP-based Services (read more about Service modes here), namely HTTP, KUBERNETES, GRPC and WEB Service modes.

To enable the clientless BeyondCorp mode, you only need to enable the isPublic field as follows:

1
kind: Service
2
metadata:
3
  name: svc1
4
spec:
5
  mode: HTTP
6
  config:
7
    upstream:
8
      url: http://nginx.local
9
  isPublic: true

When isPublic is enabled, the internet-facing Ingress accepts requests coming from the internet and proxies these requests to the corresponding Service depending on its public FQDN.

Human Access

For HUMAN Users to access a protected web app (e.g. Kubernetes or Grafana dashboards), you are advised to set the Service mode to WEB instead of just HTTP. This allows the web Portal to denote the Service as web app with a "Visit" button to make it easy for the Users to visit the homepage of that Service. Here is an example:

1
kind: Service
2
metadata:
3
  name: k8s-dashboard
4
spec:
5
  mode: WEB
6
  isPublic: true
7
  config:
8
    upstream:
9
      url: http://k8s-dashboard.svc.local:8080

Authorized HUMAN Users can now access the Service directly via their browsers at the URL https://k8s-dashboard.<DOMAIN>.

Workload Access

OAuth2 Client Credentials

The easy way for clientless WORKLOAD Users (i.e. applications that can be written in Node.js, Golang, Rust, etc...) to any HTTP-based Service (i.e. whose mode is HTTP, KUBERNETES, GRPC, or WEB ) is via a bearer access token that can be obtained through standard OAuth2 client credentials authentication flow and then using the issued bearer access token via one of the following HTTP headers: Authorization: Bearer <TOKEN> or X-Octelium-Auth: <TOKEN>. This enables your applications and microservices written in any language to access the Cluster's Services via standard OAuth2 libraries that are supported in most major programming languages without having to use any clients or specific SDKs.

You can obtain an OAuth2 client credentials Credential via the octeliumctl create cred (read more here) as follows:

octeliumctl create cred --type oauth2 --user microservice1 cred02

Now that you have the OAuth2 client ID and client secret, you can use them to authenticate to the Cluster's OAuth2 token endpoint which is located at the URL https://<DOMAIN>/oauth2/token. You can read about the OAuth2 client credentials flow authentication here.

Please note that it is the responsibility of the application to keep re-authenticating itself via the OAuth2 token endpoint https://<DOMAIN>/oauth2/token in order to keep using the Session; otherwise, the access token will simply expire according to the limits set by the Cluster (read more here) or at the User level (read more here).

Access Tokens

You can also generate access tokens as Credentials and use them directly as standard bearer access tokens. Read more here.

SDK

Another option, currently available for WORKLOAD Users used in Golang applications, is to use the octelium-go package to obtain the access token, typically by an authentication token (read more about authentication token Credentials here). The octelium-go library provides various interfaces for your HTTP or gRPC clients to use, without having to worry about periodically re-authenticating the Session. You can read more about the octelium-go library here.

Public DNS and TLS Certificate

Since public Services are exposed to the internet, you need to set the public DNS and TLS certificate of the Service. You can read more about managing public DNS here and TLS certificates here.