Architecture

Kubees architecture

The architecture split the organization clusters in three groups:

• Seed cluster, unique, on which Kubees does most of the work, it handles the database, API and web interface.
• Trunk clusters, used as pass-through to collect informations from all the clusters and forward them to the seed cluster. This kind is optionnal and intended only for organization with strict network policies that don’t want to expose the seed cluster directly.
• Leaf clusters, all the cluster being supervised by the solution.

Components

Backbone

The backbone is a distributed message queue system based on NATS, its main goal is to centralize the communication and authorization mechanisms across the fleet of clusters. It uses JWT for decentralized authentication and authorization in order to provide strong isolation between the different agents on the message queue. It is useful to overcome constraints on the network (e.g: Firewalls, reverse proxies) as described in the Intercluster connectivity section.

API

The API is the primary interface to the system for an user, it can be consumed both directly and by the WebUI. Documentation for the API can be found here

WebUI

Single page application that can be used as a federated hub for all the Kubees personas, it is intended to give an high level view for a non technical public.

Agent

Installed on all the managed clusters, the agent schedule audits, react to RPC from the seed cluster and forward informations on the NATS backbone.

Ingestion

The ingestion mechanism is used to:

• Aggregate received values from the backbone
• Persist audit results into the database
• Summarize and persist metadatas to the database

CnC

The Command and Control microservice is intendent to distribute jobs and RPC to the seed clusters.

Intercluster connectivity

Accronym	Meaning
Nats	NATS server cluster
GLN	Gateway LeafNode
C	Consumer
E	Emitter

The connectivity between cluster can be operated in both direction for the communication:

• The user can create a new target from the seed cluster, which will try to establish a connection to its agent.
• The user can define an Interconnect request on the leaf cluster, which will try to reach one of the configured trunks or seed in order to create the request. An operator will then have to approve the interconnect request in order for the cluster to be registered.

Furthermore, in order to overcome firewalls and networking constraints, the direction of the communication can be specified upon interconnect creation, so that one part cannot connect directly to the other, they will still be able to establish a communication using a technique similar to NAT hole punching