# Clientless BeyondCorp Access

> Octelium documentation. Canonical page: <https://octelium.com/docs/octelium/latest/management/core/service/clientless>.

In addition to providing access to *Services* via the private client-based mode over WireGuard/QUIC tunnels via the `octelium` CLI (read more [here](https://octelium.com/docs/octelium/latest/user/cli/connect.md)), Octelium also provides a public clientless "BeyondCorp" access mode to HTTP-based *Services*, namely `HTTP`, `KUBERNETES`, `GRPC` and `WEB` *Service* modes (read more about *Service* modes [here](https://octelium.com/docs/octelium/latest/management/core/service/overview.md#mode)), for both `HUMAN` and `WORKLOAD` *Users*.

*Diagram: BeyondCorp.* [View the diagram on the canonical HTML page](https://octelium.com/docs/octelium/latest/management/core/service/clientless).

> **Note:**
>
> [BeyondCorp](https://www.beyondcorp.com/) 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 from anywhere, including from mobile phones and tablets, just like a typical SaaS application without having to install and use an agent/client on their end.

> **Note:**
>
> You might also want to check the public anonymous mode which enables you to publicly expose HTTP-based *Service* to the public internet for public anonymous access [here](https://octelium.com/docs/octelium/latest/management/core/service/anonymous-access.md). The anonymous mode can be especially useful for hosting public websites and APIs.

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

```yaml
kind: Service
metadata:
  name: svc1
spec:
  mode: HTTP
  config:
    upstream:
      url: http://nginx.local
# !mark
  isPublic: true
```

When `isPublic` is enabled, the internet-facing [*Ingress*](https://octelium.com/docs/octelium/latest/reference/components.md#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*](https://octelium.com/docs/octelium/latest/reference/components.md#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:

```yaml
kind: Service
metadata:
  name: k8s-dashboard
spec:
  #!mark(1:2)
  mode: WEB
  isPublic: true
  config:
    upstream:
      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](https://octelium.com/docs/octelium/latest/management/core/credential.md#oauth2-client-credentials)) as follows:

```bash
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](https://octelium.com/docs/octelium/latest/user/clientless/oauth2.md).

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](https://octelium.com/docs/octelium/latest/management/core/cluster-config.md#session)) or at the *User* level (read more [here](https://octelium.com/docs/octelium/latest/management/core/user.md#session)).

### Access Tokens

You can also generate access tokens as *Credentials* and use them directly as standard bearer access tokens. Read more [here](https://octelium.com/docs/octelium/latest/management/core/credential.md#access-tokens).

### SDK

Another option, currently available for `WORKLOAD` *Users* used in Golang applications, is to use the [`octelium-go`](https://pkg.go.dev/github.com/octelium/octelium/octelium-go) package to obtain the access token, typically by an authentication token (read more about authentication token *Credentials* [here](https://octelium.com/docs/octelium/latest/management/core/credential.md#authentication-tokens)). 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](https://octelium.com/docs/octelium/latest/management/guide/sdk.md).

## 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](https://octelium.com/docs/octelium/latest/install/cluster/dns.md) and TLS certificates [here](https://octelium.com/docs/octelium/latest/install/cluster/tls-certificate.md).

## TLS in Client-based Mode

Enabling the clientless BeyondCorp access is unrelated to enabling TLS for a *Service* (read more about listening over TLS [here](https://octelium.com/docs/octelium/latest/management/core/service/overview.md#listening-over-tls)). The latter is concerned with serving the *Service* over TLS (HTTPS in the case for HTTP-based *Services*) when accessed over the client-based mode. In other words, enabling the clientless/BeyondCorp mode via `isPublic` serves the *Service* public over the standard HTTPS port regardless of whether the *Service* is serving over HTTPS or plaintext HTTP in the client-based mode. You can read more about enabling `isTLS` for HTTP-based *Services* [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#https).