Custom Resource Definitions

Overview

This project houses CustomResourceDefinitions (CRDs) related to security and compliance checks along with the code generated by Kubernetes code generators to write such custom resources in a natural way.

NAME	SHORTNAMES	APIGROUP	NAMESPACED	KIND
vulnerabilityreports	vulns,vuln	aquasecurity.github.io	true	VulnerabilityReport
configauditreports	configaudit	aquasecurity.github.io	true	ConfigAuditReport
ciskubebenchreports	kubebench	aquasecurity.github.io	false	CISKubeBenchReport
kubehunterreports	kubehunter	aquasecurity.github.io	false	KubeHunterReport

Note

We are open to suggestions for adding new or changes to the existing CRDs in the case that would enable additional third-party integrations.

VulnerabilityReport

An instance of the VulnerabilityReport represents the latest vulnerabilities found in a container image of a given Kubernetes workload. It consists of a list of OS package and application vulnerabilities with a summary of vulnerabilities grouped by severity. For multi-container workloads Starboard creates multiple instances of VulnerabilityReports, which are stored in the same namespace and are owned by this workload. Each report follows the naming convention <workload kind>-<workload name>-<container-name>.

Note

For various reasons we'll probably change the naming convention to name VulnerabilityReports by image digest (see #288).

Any static vulnerability scanner that is compliant with the VulnerabilityReport schema can be integrated with Starboard. You can find the list of available integrations here.

ConfigAuditReport

An instance of the ConfigAuditReport represents checks performed by configuration auditing tools, such as Polaris, against a Kubernetes workload's configuration. For example, check that a given container image runs as non root user or that a container has resource requests and limits set. Currently checks only relate to Kubernetes workloads, but most likely we'll extend this model to cater for other Kubernetes objects such as Services, ConfigMaps, etc (see #300).

Each report owned by the underlying Kubernetes workload and is stored in the same namespace, following the <workload-kind>-<workload-name> naming convention.

Third party Kubernetes configuration checkers, linters, and sanitizers that are compliant with the ConfigAuditReport schema can be integrated with Starboard.

Note

The challenge with onboarding third party configuration checkers is that they tend to have different interfaces to perform scans and vary in output formats for a relatively common goal, which is inspecting deployment descriptors for known configuration pitfalls.

CISKubeBenchReport

The CISKubeBenchReport is a cluster scoped resource owned by a Kubernetes node, which represents the latest result of running CIS Kubernetes Benchmark tests on that node. It's named after a corresponding node.

We do not anticipate many (at all) kube-bench alike tools, hence the schema of this report is currently the same as the output of kube-bench.

KubeHunterReport

The KubeHunterReport is a cluster scoped resource which represents the outcome of running pen tests against your cluster. Currently the data model is the same as kube-hunter's output, but we can make it more generic to onboard third party pen testing tools. There's zero to one instances of KubeHunterReports with hardcoded name cluster without any owner reference being set as there's no built-in Kubernetes resource that represents a cluster.