Octelium is a unified zero trust architecture. It can seamlessly provide an effortless zero trust, identity-based, application-layer (L7) aware secret-less access (read more about secret-less access here), via both the private client-based access over WireGuard/QUIC-based tunnels as well as the clientless (i.e. "BeyondCorp") access, to all your SaaS APIs, including REST and gRPC APIs, for all your Users, both humans and workloads, via a unified identity management at scale. These CASB capabilities can provide multiple benefits at any scale:

• All your Users, both humans and workloads, can now have a unified identity management to all your APIs using the same credentials (e.g. SSO identity providers for humans (read more here) and OAuth2 client credentials and standard bearer access tokens for workloads (read more here)).
• Unified identity-based, application-layer (L7) aware, context-aware ABAC-based access control via policy-as-code (read in detail about Policies and access control here) where you can control access way beyond what the SaaS API providers themselves can offer.
• Unified L-7 aware visibility and logging for access to all of your APIs (read more here).

Here is a simple example where you can have an API Service that's protected by a bearer access token. This Service is publicly exposed (read more about the public client-less BeyondCorp mode here) and can be accessed, for example, by workloads that can be written in any programming language via OAuth2 client credential flows (read more here) or even directly by directly issued standard bearer access tokens (read more here):

1
kind: Service
2
metadata:
3
  name: my-api
4
spec:
5
  mode: HTTP
6
  isPublic: true
7
  dynamicConfig:
8
    configs:
9
      - name: v1
10
        upstream:
11
          url: https://api.example.com
12
        http:
13
          auth:
14
            bearer:
15
              fromSecret: example-access-token

You can now apply the creation of the Service as follows (read more here):

octeliumctl apply /PATH/TO/SERVICE.YAML

Octelium also allows you to dynamically route to an upstream based on the identity and the access context via policy-as-code. Here is an example where you have 2 access tokens corresponding to 2 different accounts/tenants and where you can choose one of them depending on the Group to which the User belongs:

1
kind: Service
2
metadata:
3
  name: my-api
4
spec:
5
  mode: HTTP
6
  isPublic: true
7
  dynamicConfig:
8
    configs:
9
      - name: v1
10
        upstream:
11
          url: https://api.example.com
12
        http:
13
          auth:
14
            bearer:
15
              fromSecret: account-1-token
16
      - name: v2
17
        upstream:
18
          url: https://api.example.com
19
        http:
20
          auth:
21
            bearer:
22
              fromSecret: account-2-token
23
    rules:
24
      - condition:
25
          match: '"prod" in ctx.user.spec.groups'
26
        configName: v1
27
      - condition:
28
          match: '"dev" in ctx.user.spec.groups'
29
        configName: v2

You can also, for example, have a unified endpoint for your API and route to different upstreams (e.g. multiple versions of the same API) depending on the request's path. Here is an example:

1
kind: Service
2
metadata:
3
  name: my-api
4
spec:
5
  mode: HTTP
6
  isPublic: true
7
  dynamicConfig:
8
    configs:
9
      - name: v1
10
        upstream:
11
          url: https://v1.api.example.com
12
        http:
13
          auth:
14
            bearer:
15
              fromSecret: access-token
16
          path:
17
            removePrefix: /v1
18
      - name: v2
19
        upstream:
20
          url: https://v2.api.example.com
21
        http:
22
          auth:
23
            bearer:
24
              fromSecret: access-token
25
          path:
26
            removePrefix: /v2
27
    rules:
28
      - condition:
29
          match: 'ctx.request.http.path.startsWith("/v1")'
30
        configName: v1
31
      - condition:
32
          match: 'ctx.request.http.path.startsWith("/v2")'
33
        configName: v2

Octelium's application-layer (L7) awareness seamlessly enables you to control access using CEL and Open Policy Agent (read more here) based on HTTP request paths, methods and the JSON body of the requests. For example, a REST API whose JSON body has the following structure:

1
{
2
  "id": "abc123",
3
  "name": "user-2",
4
  "data": {
5
    "books": ["book-1", "book-2"]
6
  },
7
  "isActive": true,
8
}

Access control of such API can be as follows:

1
kind: Service
2
metadata:
3
  name: my-api
4
spec:
5
  mode: HTTP
6
  isPublic: true
7
  config:
8
    upstream:
9
      url: https://api.example.com
10
    http:
11
      enableRequestBuffering: true
12
      body:
13
        mode: JSON
14
        maxRequestSize: 100000
15
  authorization:
16
    inlinePolicies:
17
    - spec:
18
        rules:
19
        - effect: ALLOW
20
          condition:
21
            all:
22
              of:
23
              - match: ctx.request.http.method in ["PUT", "POST"]
24
              - match: ctx.request.http.bodyMap.isActive
25
              - match: ctx.request.http.bodyMap.name.startsWith("user")
26
              - match: '"book-1" in ctx.request.http.bodyMap.data.books'

This was a very short guide to show you how to use Octelium to deploy, scale, route and provide dynamic zero trust secure access to your workloads. Here are a few more related features that you might be interested in:

• Routing not just by request paths, but also by header keys and values, request body content including JSON (read more here).
• Request/response header manipulation (read more here).
• Cross-Origin Resource Sharing (CORS) (read more here).
• gRPC mode (read more here).
• Secret-less access to upstreams and injecting bearer, basic, or custom authentication header credentials (read more here).
• Exposing the API publicly for anonymous access (read more here).