3 min read

Kaphera Cloud Operator

The Kubernetes operator that creates the multi-tenant boundary (namespace, gateway, TLS, identity groups) turning a cluster into a platform with isolated tenants.

What it is

A Kubernetes operator that manages the organisational and platform layer of Kaphera Cloud: the Organisation CRD that creates the operational context (namespace, Gateway, TLS Certificate, Keycloak groups) in which EDC infrastructure and connectors run. Written in Rust using kube-rs. Unlike the kaphera-edc-operator and kaphera-edc-enablement-operator, which manage workloads and infrastructure, this operator creates the multi-tenant boundary that turns a Kubernetes cluster into a platform.

What it does for the customer

Provides the organisational isolation that makes managed and BYOC deployments possible. When an Organisation is created, the operator provisions the namespace, networking, TLS certificates, and identity groups that isolate one tenant from another. For BYOC deployments, it is the component that makes the kaphera-cloud-server and kaphera-cloud-console functional; without it, there is no organisational context to scope resources into.

Who it serves

marco-ferretti is the white-label partner building a managed connector platform under his own brand. The organisational model is what lets him isolate client environments from each other on shared infrastructure.

dirk-wassermann is the enterprise platform leader running BYOC. His team needs the multi-tenant isolation model on their own clusters, managed by Kaphera but owned by them. The source-available Elastic licence gives him a credible exit path: he can take over operations without rebuilding the organisational layer from scratch.

Not needed by teams that only want to deploy connectors into existing namespaces; those teams use the kaphera-edc-operator and kaphera-edc-enablement-operator directly.

Why this licence: Source-available — Elastic

The Organisation CRD is where commodity infrastructure becomes a platform product. It encodes Kaphera’s operational model: how tenants are isolated, how identity is scoped, how networking is configured per organisation. Open-sourcing it would let competitors offer managed services on Kaphera’s platform design without contributing back. Source-available under the Elastic licence keeps the code readable and auditable (customers can inspect exactly how their tenant isolation works) while protecting the commercial model. Same approach as HashiCorp Vault.

How it relates to other artefacts

Depends on the kaphera-edc-enablement-operator for infrastructure resources. Provides the organisational context that the kaphera-cloud-server and kaphera-cloud-console operate within. The kaphera-edc-operator connectors are deployed into namespaces created by this operator. In self-hosted scenarios without this operator, the [[kaphera-cli|kaphera CLI]] and kaphera-cloud-terraform-provider talk directly to the EDC and Enablement operators via the Kubernetes backend.

flowchart LR
  CR["Organisation CR<br/>(declared)"]
  CTL["Cloud Operator<br/>controller"]
  NS["Namespace"]
  GW["Gateway + TLS"]
  KC["Keycloak group"]
  CR --> CTL
  CTL --> NS
  CTL --> GW
  CTL --> KC
  NS --> RC["Reconcile loop"]
  GW --> RC
  KC --> RC
  RC --> CTL
  • kaphera-edc-operator: connector lifecycle operator that runs inside the namespaces this operator creates.
  • kaphera-edc-enablement-operator: supporting-services operator this depends on.
  • kaphera-cloud-server: the API server that runs against the organisational context this operator manages.
  • marco-ferretti: the white-label partner whose multi-client isolation depends on this operator’s Organisation CRD.
  • dirk-wassermann: the BYOC enterprise lead whose source-availability access path runs through this operator.

Graph View

Backlinks