Reports Server

Reports server provides a scalable solution for storing policy reports and cluster policy reports. It moves reports out of etcd and stores them in an alternate database instance.

Why Reports Server?

Before understanding the benefits of reports server, it is essential to have a look at the reasons that makes moving reports out of etcd desirable.

Reasons to Transition Away from etcd

  • Capacity Constraints: etcd has a maximum size of 8GB. Reports, being relatively large objects, can quickly consume this capacity in larger clusters with numerous report producers.
  • Performance Under Load: High levels of report activity (e.g., cluster churn, scanning, analytics) require significant data buffering by the API server, potentially leading to API unavailability.
  • Data Nature: Reports are ephemeral and analytical in nature, not requiring CAP guarantees. As such, they are better suited for storage outside the transactional etcd database.
  • Philosophical Alignment: Analytical data like reports should ideally be stored in a system designed for analytical queries, such as a relational database.

Benefits of reports server

  • Reduced Load on etcd and API Server: By relocating reports, the load and capacity limitations of etcd and the API server are alleviated.
  • Improved Efficiency for Consumers:
    • Report consumers often require analytical or aggregate data queries. The Kubernetes API is not optimized for such queries.
    • For instance, querying all reports with a CVSS severity of 8.0 or higher requires retrieving and parsing all reports via the API, which is inefficient.
    • With reports stored in a relational database, consumers can perform robust queries directly, improving performance and enabling new use cases.
    • This approach can replace certain exporters and streamline reporting workflows.

Prerequisites

  • Helm: Refer to the official docs for installation.
  • Kubernetes Cluster: Any CNCF compliant Kubernetes distribution.

Installation

Installing Reports Server Natively with Enterprise Kyverno

 helm repo add nirmata https://nirmata.github.io/kyverno-charts/
 helm repo update nirmata
 helm install kyverno --namespace kyverno --create-namespace nirmata/kyverno  --set crds.reportsServer.enabled=true --set reports-server.install=true

For a complete list of values, refer to values.yaml.

Installing Reports Server Independent of Enterprise Kyverno

The Reports Server serves certain report CRDs through its APIService. At the same time, Enterprise Kyverno expects these CRDs to exist for policy reporting. If both Kyverno and the Reports Server try to define or serve these CRDs simultaneously, the Kubernetes apiserver may fail to reconcile duplicate API paths. This is a known limitation in upstream Kubernetes (see Kubernetes Issue #122668).

To avoid these conflicts:

  • Deploy Reports Server independently first
  • Confirm its APIService is fully ready
  • Then install Enterprise Kyverno separately

This ordering guarantees the CRDs are correctly served and avoids temporary crash loops or installation failures in Kyverno.

Note: The below command installs reports-server in etcd mode. For Postgres, see the section below.

Add and update Helm repo.

 helm repo add nirmata https://nirmata.github.io/kyverno-charts/
 helm repo update nirmata

 helm install reports-server -n kyverno nirmata/reports-server --create-namespace

 helm install kyverno --namespace kyverno --create-namespace nirmata/kyverno  --set crds.reportsServer.enabled=true

Installing Reports Server using configurations

There are two configurations available for installing the Reports Server in a production cluster:

  • Reports server with embedded etcd storage: Store reports in a high-availability (HA) etcd instance.
  • Reports server with managed postgres: Use a centralized postgres database in or outside of the cluster.

Embedded etcd storage

To install the Reports Server with embedded etcd storage:

Using Helm Commands:

 helm repo add nirmata https://nirmata.github.io/kyverno-charts/
 helm repo update nirmata
 helm install reports-server -n kyverno nirmata/reports-server --create-namespace

Managed Postgres

To configure the Reports Server with a PostgreSQL instance:

Using Helm Commands:

 helm repo add nirmata https://nirmata.github.io/kyverno-charts/
 helm repo update nirmata
 helm install reports-server -n kyverno nirmata/reports-server --create-namespace \
         --set config.etcd.enabled=false \
         --set config.db.host=<Host_Name> \
         --set config.db.name=<DB_Name> \
         --set config.db.user=<Postgres_username> \
         --set config.db.password=<Postgress_password>

Note: Obtain the hostname, database name, PostgreSQL username, and password from your PostgreSQL instance.

Managed Postgres in AWS

Reports Server can be installed with managed postgres in AWS. Create a postgres instance in AWS using Amazon RDS and install the reports-server chart using the above command. Refer to the official AWS documentation for creating the postgres instance. Get the hostname, dbname, postgres username, postgres password, etc., from the postgres instance and fill the values in helm values.

Migration from etcd to reports-server

When the Reports Server is enabled, migration from etcd occurs automatically under the following conditions:

  • The cluster has Kyverno already installed.
  • The cluster has policy reports crds already installed.

QA Testing

The Reports Server has been verified on both amd64 and arm64 architectures, ensuring robust performance and compatibility.