Vigil

Vigil is the identity-aware proxy (IaP) that intercepts requests sent to the actual protected resource and decides whether the the request should be accepted or denied according to the relevant Policies of that request (read more about Policies and access control here). Vigil can be called a policy enforcement point (PEP) as the policy decision is actually made in another component called Octovigil.

Octovigil

Octovigil is a policy decision point (PDP) that actually does the authentication and authorization. For every new request sent to the identity-aware proxy, Vigil, the request information (e.g. private WireGuard IP address, application-layer information such as HTTP headers, etc...) is forwarded to Octovigil in order to first identify the Session and its User, and then to authorize the request according the Policies relevant to the request (read more about Policies and access control here).

API Server

Octelium's API Server is the interface using which Users can interact with the Cluster. The API Server is a gRPC server that implements various APIs (or "services" according to gRPC nomenclature). In order to interact with the API Server, Users must first obtain a valid Session. The API Server currently implements 2 APIs:

• The User API: Used by any User mainly to connect to/disconnect from the Cluster and discover its Services.

• The Core API: Used by "administrator" Users to control the Cluster's core resources such as Services, Users, Groups, Sessions, Devices, etc....

Gateway Agent

As the name implies, the Gateway Agent is an agent that runs on every Kubernetes node that is part of the data plane in the Octelium Cluster (i.e. Gateway) and it is deployed as a Kubernetes daemonset. Gateway Agents are responsible for maintaining the Gateways and their WireGuard/QUIC network interfaces. Gateways are where the tunneled WireGuard/QUIC traffic is terminated and from there the inner traffic is transported to the pod running the destination Service.

Resource Server

The Resource Server is a gRPC server that acts as interface between the various Cluster components (e.g. Nocturne, API Server, etc...) and the primary storage backend, currently PostgreSQL, that stores the Cluster resource objects. The Resource Server offers a CRUD-like API for the different Cluster components to control the Cluster resource objects in a unified and clean way.

Nocturne

Nocturne is the main controller of the Cluster's resources which watches for changes submitted to the Resource Server and acts accordingly (e.g. when you create a new Service, Nocturne creates the kubernetes deployment/daemonset that contains the Vigil instance(s) implementing that Service). It also does various management and garbage collection operations for the various resource objects in the Cluster.

DNS Server

The Cluster private DNS Server resolves the private FQDN for the Cluster's Services. The DNS Server itself runs as a typical Service that is accessible by all Users. For the case of Services implemented by multiple replicas (read more here), the DNS Server automatically does round robin load balancing among the different addresses of such Services.

Auth Server

Auth Server is the Cluster's authentication server. It implements the Auth gRPC API for the Users to authenticate themsleves via authentication token Credentials (read more here), re-authenticate their Sessions via Authenticators (read more here), or web identity providers (IdPs) such as Open ID Connect and SAML 2.0 providers (read more here).

Portal

Portal is a WEB Service that is exposed publicly (read more about the public BeyondCorp mode here). Portal is accessible by all HUMAN Users and acts as a dashboard for the Users to discover the Cluster's Services.

Ingress

Ingress is the proxy sitting between the external world (i.e. downstreams coming from the internet), and some Octelium components (currently the API Server and Portal). Also Ingress acts as a transparent proxy between Users and BeyondCorp Services (read more about here). Ingress actually is comprised of two components: the data-plane component which is represented by Envoy proxies and a control-plane component that controls the Envoy proxies.

Genesis

Genesis is the installer that runs from within the hosting Kubernetes cluster as a Kubernetes job to install (read more here) and upgrade (read more here) the Octelium Cluster.