BeyondCorp is a zero trust networking architecture that allows users, typically human users, to access protected resources in a client-less 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 exactly like a typical SaaS application without having to install and use an agent/client on their side.

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

To enable the client-less 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 in order for 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

HUMAN Users who can access web-app Services directly via their browsers.

Workload Access

OAuth2 Client Credentials

The easy way for client-less 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 use specific SDKs.

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

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

Now that you have the client ID and 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 credential flow authentication here.

Please note that it's 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 just 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 that is currently available for WORKLOAD Users used by 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.