Octelium as an API Gateway

Using Octelium as a scalable, secure API Gateway is almost effortless. This is a simple example where you can have an API Service, publicly exposed (read more about the public client-less BeyondCorp mode here) that has 2 upstreams, defined by the 2 named configs v1 and v2, where the routing depends on the request's prefix:

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

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

octeliumctl apply /PATH/TO/SERVICE.YAML

Octelium doesn't just enable you to dynamically route to an upstream based on a request path, but since it's built as a zero trust architecture, it can dynamically route to an upstream based on the identity and the access context too. Here is an another example:

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

You can also use upstreams that are protected by their own credentials such as bearer tokens (read more about secret-less access in HTTP here). Here is an example:

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

And you can also deploy and scale your own containerized microservices including those that are served via private registries that are protected with credentials. Here is an example:

First you create the Secret for the registry's password as follows:

octeliumctl create secret ghcr-token

And then you create the Service as follows:

1kind: Service
2metadata:
3  name: my-api
4spec:
5  mode: HTTP
6  isPublic: true
7  dynamicConfig:
8    configs:
9      - name: v1
10        upstream:
11          container:
12            image: ghcr.io/org/my-api:v1
13            port: 80
14            replicas: 2
15            credentials:
16              usernamePassword:
17                username: org
18                password:
19                  fromSecret: ghcr-token
20        http:
21          path:
22            removePrefix: /v1
23      - name: v2
24        upstream:
25          container:
26            image: ghcr.io/org/my-api:v2
27            port: 80
28            replicas: 2
29            credentials:
30              usernamePassword:
31                username: org
32                password:
33                  fromSecret: ghcr-token
34        http:
35          path:
36            removePrefix: /v2
37    rules:
38      - condition:
39          match: 'ctx.request.http.path.startsWith("/v1")'
40        configName: v1
41      - condition:
42          match: 'ctx.request.http.path.startsWith("/v2")'
43        configName: v2

You can also opt to choose to provide anonymous public access instead of using Octelium to provide authentication and access control. You might want to use anonymous access, for example, for public APIs or whenever you want to handle your own authentication and authorization at the upstream's side. You can read more about the anonymous access mode here.

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).
Application layer-aware ABAC access control via policy-as-code using CEL and Open Policy Agent (read more here).