Skip to content

Welcome to Compliant Kubernetes

Comparison of vanilla Kubernetes and Compliant Kubernetes

Compliant Kubernetes is a Certified Kubernetes distribution, i.e., an opinionated way of packaging and configuring Kubernetes together with other projects. Compliant Kubernetes reduces the compliance burden, as required to comply with:

Why Compliant Kubernetes?

Kubernetes has established itself as a go-to solution for high development velocity without vendor lock-in. However, vanilla Kubernetes is not usable in regulated industry, since it is not secure by default, nor by itself. Therefore, if you want to benefit from the speed of cloud native development in regulated industries, Kubernetes needs to be carefully configured. Furthermore, Kubernetes is a laser-focused project ("Make each program do one thing well."), so it needs to be complemented with other cloud native projects.

Compliant Kubernetes fills this gap.


Below we present the architecture of Compliant Kubernetes, using the C4 model.

Level 1: System Context

Let us start with the system context.

C4 Model, Level 1 Diagram

Compliance imposes restrictions on all levels of the tech stack. Your compliance focus should mostly lie on your application. Compliant Kubernetes ensures that the platform hosting your application is compliant. Finally, you need the whole software stack on a hardware that is managed in a compliant way, either via an ISO 27001-certified cloud provider or using on-prem hardware.

Level 2: Clusters

Most regulations require logging to a tamper-proof environment. This is usually interpreted as an attacker gaining access to your application should not be able to delete logs showing their attack and the harm caused by their attack.

To achieve this, Compliant Kubernetes is implemented as two Kubernetes clusters

  • A workload cluster, which hosts your application, and
  • A service cluster, which hosts services for monitoring, logging and vulnerability management.

C4 Model, Level 2 Diagram


Due to technical limitations, some compliance-related components still need to run in the workload cluster. These are visible when inspecting the workload cluster, for example, via the Kubernetes API. Currently, these components are:

  • Falco, for intrusion detection;
  • Prometheus, for collecting metrics;
  • Fluentd, for collecting logs;
  • OpenPolicyAgent, for enforcing Kubernetes API policies.

Note that, the logs, metrics and alerts produced by these components are immediately pushed into the tamper-proof logging environment, hence this technical limitation does not weaken compliance.