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 is supported out of the box with N4K helm chart, default disbaled.

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 an high-availability (HA) etcd instance.
  • Reports server with managed postgres: Use a centralised 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 kyverno -n kyverno nirmata/kyverno  --create-namespace --set reports-server.enabled=true

Updating values.yaml:

reports-server:
  enabled: true

  config:

    etcd:
      enabled: true
      endpoints: ~
      insecure: true

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 kyverno -n kyverno nirmata/kyverno --create-namespace \
         --set reports-server.enabled=true \
         --set reports-server.config.etcd.enabled=false \
         --set reports-server.config.db.host=<Host_Name> \
         --set reports-server.config.db.name=<DB_Name> \
         --set reports-server.config.db.user=<Postgres_username> \
         --set reports-server.config.db.password=<Postgress_password>

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

Updating values.yaml:

reports-server:
  enabled: true
  config:
      etcd:
        # -- we need to set it to false since by default reports-server runs in etcd mode.
        enabled: false
        endpoints: ~
        insecure: true  
        db:
        # -- If set, database connection information will be read from the Secret with this name. Overrides `db.host`, `db.name`, `db.user`, and `db.password`.
        secretName: ""

        # -- Database host
        host: reports-server-cluster-rw.reports-server
        # -- The database host will be read from this `key` in the specified Secret, when `db.secretName` is set.
        hostSecretKeyName: "host"

        # -- Database name
        name: reportsdb
        # -- The database name will be read from this `key` in the specified Secret, when `db.secretName` is set.
        dbNameSecretKeyName: "dbname"

        # -- Database user
        user: app

        # -- The database username will be read from this `key` in the specified Secret, when `db.secretName` is set.
        userSecretKeyName: "username"

        # -- Database password
        password: password

        # -- The database password will be read from this `key` in the specified Secret, when `db.secretName` is set.
        passwordSecretKeyName: "password"

        # -- Database SSL
        sslmode: disable

        # -- Database SSL root cert
        sslrootcert: ""

        # -- Database SSL key
        sslkey: ""

        # -- Database SSL cert
        sslcert: ""
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.