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

Report Server Installation Advisory

Starting with N4K 1.13.6 and continuing in 1.14, we have fully removed the built-in Reports Server dependency from the N4K Helm chart until a proper fix is available. This change addresses issues introduced by recent Helm chart and CRD updates, which could cause Kyverno pods to temporarily enter crash loops during startup when deploying both components together. Although these pods would eventually stabilize after several restarts, this behavior could result in unnecessary disruption.

To prevent these problems, we strongly recommend deploying the Reports Server separately from N4K for now. You should still include the Reports Server in your environment, but install it using a dedicated Helm deployment rather than relying on a combined chart.

N4K and Reports Server Dependency

The OSS commit (PR #13361) introduced a crds.reportsServer.enabled flag which allowed to skip the installation of report related CRDs in Kyverno. This originates from an upstream issue in Kubernetes (Issue #122668) which occurs when existing CRDs conflict with the ones served by the APIService (in our case, the Reports Server).

Therefore, we do not want to install the reports related CRDs when Reports Server is present in the cluster. But for a successfull Kyverno install, either the APIService needs to be ready or have the reports CRDs present. To avoid this issue, we recommend installing Reports Server first and then Enterprise Kyverno.

The rest of this documentation will provide instructions on installing two separate Helm charts.

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 rs https://nirmata.github.io/reports-server/
 helm repo update rs
 helm install reports-server -n kyverno rs/reports-server --create-namespace --set apiServicesManagement.installApiServices.enabled=true

Managed Postgres

To configure the Reports Server with a PostgreSQL instance:

Using Helm Commands:

 helm repo add rs https://nirmata.github.io/reports-server/
 helm repo update rs
 helm install reports-server -n kyverno rs/reports-server --create-namespace \
         --set apiServicesManagement.installApiServices.enabled=true \
         --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.

Installing 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

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

QA Testing

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