The current available plugins of a Zora installation can be listed by running the following command:
kubectl get plugins -n zora-system
NAME IMAGE TYPE AGE
marvin ghcr.io/undistro/marvin:v0.2.1 misconfiguration 14m
popeye ghcr.io/undistro/popeye:v0.11.3 misconfiguration 14m
trivy ghcr.io/aquasecurity/trivy:0.48.2 vulnerability 14m
Each item listed above is an instance of
Plugin CRD and represents the execution configuration of a plugin.
More details can be seen by getting the YAML output of a plugin:
kubectl get plugin marvin -o yaml -n zora-system
Currently, Zora has two plugin types:
which determine the focus of plugin scans.
vulnerabilityplugins scan cluster images for vulnerabilities, and their results are stored as instances of
misconfigurationplugins scan cluster resources for potential configuration issues, and their results are available as instances of the
Both result types can be listed using
kubectl, and some aliases are supported for your convenience,
as shown in the following commands:
kubectl get vulnerabilityreports
kubectl get vuln
kubectl get vulns
kubectl get vulnerabilities
kubectl get clusterissues
kubectl get issue
kubectl get issues
kubectl get misconfig
kubectl get misconfigs
kubectl get misconfigurations
The results are only available after a successful scan, in the same namespace as the
ClusterScan (default is
How plugins work¶
Starting from a
Plugin and a
ClusterScan, Zora manages and schedules scans by applying
Pods where the scans run, include a "sidecar" container called worker alongside the plugin container.
After the plugin completes its scan, it needs to signal to Zora (worker) by writing out the path of the results file into a "done file".
Worker container waits for the "done file" to be present,
then transforms the results and creates
VulnerabilityReports (depending on the plugin type).
This is the aspect that currently prevents the full declarative integration of new plugins. The code responsible for transforming the output of each plugin into CRDs is written in Go within the worker.
Any contributions or suggestions in this regard are greatly appreciated.
This architecture for supporting plugins is inspired by Sonobuoy, a project used for CNCF conformance certification.