Cluster configuration, or simply ClusterConfig, acts the sole source of truth for all global configurations and settings of the Cluster. ClusterConfig is created automatically upon the Cluster installation and can be updated declaratively via the command octeliumctl apply (read more here). You can read the entire Cluster configuration in the reference here.

You can get the ClusterConfig as follows:

octeliumctl get cc
# OR
octeliumctl get clusterconfig -o json

Session

Users can interact with a Cluster and access its Services as long as their Sessions are valid (read more about Session management here). A Session has a duration after which the Session expires and automatically gets deleted by the Cluster. It's recommended that the Session's duration should be as short as possible without becoming too annoying especially for HUMAN Users. The current fallback value for access token duration is 4 hours but it might change in the future.

You can set your own Session duration configuration as follows:

1
kind: ClusterConfig
2
metadata:
3
  name: cluster-config
4
spec:
5
  session:
6
    human:
7
      clientDuration:
8
        days: 1
9
      clientlessDuration:
10
        hours: 10
11
      maxPerUser: 32
12
      accessTokenDuration:
13
        hours: 4
14
      refreshTokenDuration:
15
        hours: 18
16
    workload:
17
      clientDuration:
18
        months: 6
19
      clientlessDuration:
20
        weeks: 1
21
      maxPerUser: 100
22
      accessTokenDuration:
23
        hours: 4
24
      refreshTokenDuration:
25
        weeks: 2

These Cluster-wide Session duration values can be overridden per User basis. You can read more here.

Device

Octelium enables you to control Device related configurations (read more about Devices here). For example, you can explicitly defined the default state of a new registered Device. By default, a Device's default state is set to ACTIVE, however, you can override that choice to PENDING or REJECTED. You can also set a per-User limit as follows:

1
kind: ClusterConfig
2
metadata:
3
  name: cluster-config
4
spec:
5
  device:
6
    human:
7
      maxPerUser: 32
8
      defaultState: PENDING
9
    workload:
10
      maxPerUser: 100
11
      defaultState: ACTIVE

Gateway

Octelium enables you to control the rotation duration of the Gateways WireGuard keys as follows:

1
kind: ClusterConfig
2
metadata:
3
  name: cluster-config
4
spec:
5
  gateway:
6
    wireguardKeyRotationDuration:
7
      hours: 6

Ingress

You can choose to use the useForwardedForHeader field to enable the usage of the X-Forwarded-For header by the Cluster to obtain the downstream's public IP address. The downstream's IP address is mainly stored in the Session and can be used via your Policies to control access to Services.

1
kind: ClusterConfig
2
metadata:
3
  name: cluster-config
4
spec:
5
  ingress:
6
    useForwardedForHeader: true

DNS

The Cluster automatically serves private DNS, deployed as a typical Service that can be accessed by all, to resolve the domain names of the Cluster's Services to their IP addresses. Moreover, that private DNS Service can also resolve domain names outside the Cluster domain by proxying the requests to a server that is chosen randomly from a list of fallback DNS servers. Both UDP as well as DNS-over-TLS servers are supported. Here is an example:

1
kind: ClusterConfig
2
metadata:
3
  name: cluster-config
4
spec:
5
  dns:
6
    fallbackZone:
7
      servers:
8
        - dns://8.8.8.8
9
        - udp://1.1.1.1
10
        - tls://8.8.8.8
11
        - tls://1.1.1.1
12
        - dns://custom-dns-server:8053

The private DNS Service can also cache the results of the fallback servers. Here is an example:

1
kind: ClusterConfig
2
metadata:
3
  name: cluster-config
4
spec:
5
  dns:
6
    fallbackZone:
7
      servers:
8
        - tls://8.8.8.8
9
        - tls://1.1.1.1
10
      cacheDuration:
11
        seconds: 30
12
    

Authorization

You can define global Polices (read more here) that are always triggered across all the Cluster's requests as follows:

1
kind: ClusterConfig
2
metadata:
3
  name: cluster-config
4
spec:
5
  authorization:
6
    policies: ["pol-1", "pol-2"]
7
    inlinePolicies:
8
      - spec:
9
          rules:
10
            - effect: DENY
11
              condition:
12
                match: '"junior" in ctx.user.spec.groups && ctx.namespace.metadata.name == "production"'