First of all thanks a lot for the amazing project! We are currently in the evaluation / PoC phase, however, we think we might have found a right fit for us!

A few enhancements I would like to propose on the templating of the Grafana dashboards:

• I believe that in multi-cluster setups (e.g. in our case with Thanos) the Grafana dashboards could use a cluster label => probably the metrics subchart should allow this with a variable or something
• Probably also to allow multi-teams setups, could be a good idea to allow further filtering using labels (added to the metrics from labels of the PolicyReport and ClusterPolicyReport CRDs (e.g. the ability to filter using an owner or an app metric label that get transmitted from the labels on the CRDs)
• ~~I also think the UID of the Prometheus Datasource should be given as a parameter. Or else configure all dashboards to be like the ClusterPolicyReport Details; having the datasource as a variable. Again the usecase here is that we are using a different UID for the Prometheus datasource (not prometheus rather thanos in our case)~~
• As a plus, would be really good if one could control which dashboard (among the available 3 dashboards) should be created. Probably an additional boolean flag for each dashboard would be really good.

Alternative:

We would need to disable the dashboards and construct them manually again for our needs; which is really suboptimal.

Hi!

So I have latest policy-reporter Helm chart (2.10.0) and I have the monitoring enabled.

monitoring:
  enabled: true
  serviceMonitor:
    labels:
      release: kube-prometheus-stack
  plugins:
    kyverno: true
  grafana:
    # required: namespace of your Grafana installation
    namespace: monitoring-system
    dashboards:
      # Enable the deployment of grafana dashboards
      enabled: true
      # Label to find dashboards using the k8s sidecar
      label: grafana_dashboard
    folder:
      # Annotation to enable folder storage using the k8s sidecar
      annotation: grafana_folder
      # Grafana folder in which to store the dashboards
      name: Big Brother

What is interesting that these 3 Dashboards worked on Monday and I did no changes on the policy-reporter itself. But what I did is a couple of kube-prometheus-stack Helm chart upgrades. I didn't see anything dangerous there, but my suspicion is that something changed that the policy-reporter is expecting.

On Monday I did upgrade from 36.2.1 -> 36.6.1 and 36.6.1 -> 36.6.2 (nothing special in values file) On Wednesday 36.6.2 -> 37.0.0 (here they changed metricRelabelings and cAdvisorMetricRelabelings) On Thursday 37.0.0 -> 37.2.0 (nothing special in values file)

Not sure when the dashboards stopped working, but they worked on Monday and yesterday after the upgrade I got this:

Or maybe I am on the wrong track here?

Thanks!

I am running 1.8.9 and see the following log entries when starting my policy-reporter pod. Is the ERROR legit?

2021/09/07 16:00:39 [INFO] UI configured
2021/09/07 16:00:52 [ERROR] No PolicyReport CRDs found
2021/09/07 16:01:09 [INFO] Resource Found: wgpolicyk8s.io/v1alpha1, Resource=clusterpolicyreports
2021/09/07 16:01:09 [INFO] Resource Found: wgpolicyk8s.io/v1alpha2, Resource=policyreports

The following CRDs exist on the system since this cluster is running Kyverno 1.4.2

clusterpolicies.kyverno.io                    2021-09-02T15:13:05Z
clusterreportchangerequests.kyverno.io        2021-09-02T15:13:05Z
generaterequests.kyverno.io                   2021-09-02T15:13:05Z
policies.kyverno.io                           2021-09-02T15:13:05Z
reportchangerequests.kyverno.io               2021-09-02T15:13:05Z

I deployed a set of kyverno with policies, policy exporter and policy exporter UI on cluster A, able to see the policy reports from UI

Configured one more setup of kyverno with policies, policy exporter on cluster B, but this time without policy expoter UI. In helm chart values.yaml of policy exporter, for UI url field, i gave fqdn of cluster A policy UI url.

After installing of the setup, i see the reports are pushed. I able to see report error from policy exporter log, but unable to see from dashbaord by filtering cluster or namespace etc.. How can we do this multi cluster UI setup

Shouldn't we set automountServiceAccountToken: "false" in deployment manifest? Any ideas why we set it to true instead?

$ helm install policy-reporter policy-reporter/policy-reporter --set kyvernoPlugin.enabled=true --set ui.enabled=true --set ui.plugins.kyverno=true  -n policy-reporter --create-namespace

Error: INSTALLATION FAILED: admission webhook "validate.kyverno.svc-fail" denied the request:

resource Deployment/policy-reporter/policy-reporter-kyverno-plugin was blocked due to the following policies

restrict-automount-sa-token:
  autogen-validate-automountServiceAccountToken: 'validation error: Auto-mounting
    of Service Account tokens is not allowed. Rule autogen-validate-automountServiceAccountToken
    failed at path /spec/template/spec/automountServiceAccountToken/'

Rule:

spec:
  background: true
  rules:
  - match:
      any:
      - resources:
          kinds:
          - Pod
    name: validate-automountServiceAccountToken
    validate:
      message: Auto-mounting of Service Account tokens is not allowed.
      pattern:
        spec:
          automountServiceAccountToken: "false"
  validationFailureAction: enforce

cc @developer-guy

Hi.

I am currently trying to configure email reporting. Unfortunately I could only find a way to specify the mailserver credentials in the values.yaml file. The file is going to be pushed to my gitops repository. Since the credentials are unencrypted in the values.yaml file, they are exposed to everyone who is able to access my git repository.

I would rather like to create a secret containing the mailserver credentials beforehand and just reference it in the values.yaml file.

Could you implement a way to reference a secret in the values.yaml file?

Thanks

Hi. I can't enable customFields for elasticsearch.

I used policy-reporter-2.13.2 Below is a part of values for elasticsearch and for slack, and messages sent to them. Elastic message does not contain a custom field, but Slack message does.

I double-checked that same config values are in k8s, and version of deployed pod is ghcr.io/kyverno/policy-reporter:2.10.1

elasticsearch:
  certificate: '/var/tmp/cacert.crt'
  customFields:
    - cluster: 'cluster1'
  host: "***"
  index: "sec-kyverno"
  username: "***"
  password: "***"
  rotation: "daily"
  minimumPriority: "warning"
  skipExistingOnStartup: true
slack:
  webhook: "***"
  customFields:
    - cluster: 'cluster1'
  minimumPriority: "warning"
  skipExistingOnStartup: true

{
  "_index": "sec-kyverno-2022.10.25",
  "_type": "event",
  "_id": "4fW1DoQBY5GgZkUiFVgc",
  "_version": 1,
  "_score": null,
  "_source": {
    "Message": "Running as root is not allowed. The fields spec.securityContext.runAsUser, spec.containers[*].securityContext.runAsUser, spec.initContainers[*].securityContext.runAsUser, and spec.ephemeralContainers[*].securityContext.runAsUser must be  set to a number greater than zero ",
    "Policy": "require-no-container-root",
    "Rule": "no-run-as-root-user",
    "Status": "fail",
    "Severity": "high",
    "Category": "Pod Security Standards (Restricted)",
    "Source": "Kyverno Event",
    "Timestamp": "2022-10-25T10:36:57Z",
    "Properties": {
      "eventName": "require-no-container-root.172144711e9ed465",
      "time": "2022-10-25T10:36:57Z"
    },
    "Resource": {
      "APIVersion": "",
      "Kind": "Pod",
      "Name": "test3-1337",
      "Namespace": "1337",
      "UID": ""
    },
    "Priority": "error",
    "Scored": false
  },
  "fields": {
    "Timestamp": [
      "2022-10-25T10:36:57.000Z"
    ]
  },
  "sort": [
    1666694217000
  ]
}

Hi,

great product in combination with Kyverno!

Just noticed the issue of Policy Reporter showing old Pod names failing after changes that make those resources pass the validation.

Restarting Policy Reporter is a solution (now).

Not sure, but it seems some occasional garbage collecting/removal of old records for resources that do not exist anymore in the cluster might be a solution?

Thank you, Alen

Our policy reporter UI regularly responds very slowly and sometimes an error message appears : Unable to retrieve all Data from the Server

In the logs :

2022/06/02 16:20:38 http: proxy error: context canceled
2022/06/02 16:20:44 http: proxy error: context canceled
2022/06/02 16:20:44 http: proxy error: context canceled
2022/06/02 16:20:44 http: proxy error: context canceled

When we update a kyverno policy, the information takes a long time to appear in the UI whereas the report CRD has already been updated.

Any idea about a configuration we can tune to improve this please ?

Additinnal notes :

• Version : chart v2.8.0
• We use policy reporter for kyverno reports only

I happen to be one of the folks who don't use Helm, Kustomize, etc.; so trying to get this stood up has been mostly reverse engineering the Helm chart. There are some places that aren't quite clear to me how to adapt, so even a globbed yaml manifest of the associated resources to install via kubectl [apply|create] -f <some path to maniest>.yaml would be very welcomed.

Kyverno's own Quick Start page has this, for example: kubectl create -f https://raw.githubusercontent.com/kyverno/kyverno/main/definitions/release/install.yaml

awesome project. Just wondering about options how multiple teams in cluster can have different access level to UI and get separate notification back-ends. Are there any road-map in this direction ?

Currently each change of a target requires a redeployment of Policy Reporter, to improve this behavior my idea would be to support runtime configuration of targets via ConfigMaps/Secrets with special labels.

Like the prom-operator uses config maps to define and configure dashboards, Policy Reporter should use ConfigMaps/Secrets to add/remove/update new targets at runtime without redeployments.

Currently it's possible to route resources to targets / channels based on namespace, source, policy and priorities.

For most cases this works fine but there are situations where a more fine grained / flexibel approach is needed. To achieve this I would like to add an labelSelector filter to route a result based on the labels of the related resource.

Requirements:

• Read permissions for the associated resources. (Resource labels are not part of the PolicyReport and must be fetched separately).

Rewrite Policy Reporter UI based on modern frontend stack

• Upgrade from VueJS 2 to VueJS 3
• Upgrade from NuxtJS 2 to NuxtJS 3
• Upgrade from Vuetify 2 to Vuetify 3
• Switch from Webpack to Vite

Improved structure for PolicyReportResults

Ideas:

• Resolve splitting between PolicyReport and ClusterPolicyReport pages

  • Create Pages based on sources [Kyverno, Falco, Kube Bench, etc...]
  • Splitt between Categories (?)

• New subpages for a single resource with all available information from different sources

• Timeline charts for Logs page

Configure an optional OpenID Connect Provider to enable Authentication for Policy Reporter UI

• Policy Reporter UI will only provide the API and configuration
• Possible Libraries
  • https://github.com/coreos/go-oidc
  • https://github.com/zitadel/oidc

Hi,

I raised issue at kyverno/kyverno (https://github.com/kyverno/kyverno/issues/4136) But think once again, it is only policy-reporter problem.

how about use kyverno/policy-reporter for helm chart repo like other component?

Thanks,

Hi,

I am exploring ways to export policy violations to AWS Security Hub. Is this something you've considered as part of this project? Are you aware of any other approach to achieve that?

Thanks!