CRDs description

[bygui86]

Hi guys,

Thank you for this amazing tool.
I read almost 100% of the documentation but I cannot find a good description of CRDs, where can I find it?
Maybe if not present it would be a good idea to add it.
In order to better understand reports :)

Thanks in advance for any help!

[danielpacak]

Hi @bygui86 That's a good question. We only have a list of CRDs used by Starboard documented at https://aquasecurity.github.io/starboard/crds/, but we haven't described them yet. I agree that we should do that so you can get an idea of different kinds of reports without reading the source code.

Until we update the official documentation, here's a quick summary:

• VulnerabilityReport - an instance of such report represents container vulnerabilities, i.e. list of OS package and / or application vulnerabilities with a summary of vulnerabilities grouped by severity. It's owned by Kubernetes workload (e.g. ReplicaSet or unmanaged Pod). It follows the naming convention <workload kind>-<workload name>-<container-name>. For multi-container workloads Starboard creates multiple instances of VulnerabilityReports. Each report is stored in the same namespace as the underlying workload.

  For various reasons we'll probably change that naming convention to name VulnerabilityReports by image digest (see [operator] Cannot create vulnerability report because name is too long #288)

  We assume that other security vendors might integrate with Starboard and comply with the VulnerabilityReport schema.

• ConfigAuditReport - an instance of such report represents Kubernetes resource configuration checks performed by configuration auditing tools such as Polaris. For example, check that a given container image runs as non root or has resource requests and limits specified. Currently the checks relate to Kubernetes workloads but most likely we'll extend this model to cater for other Kubernetes objects such as Services, ConfigMaps, etc (see I would like to incorporate a new security check OSS tool into the starboard. #300). Each report is owned by Kubernetes workload and it follows the <workload-kind>-<workload-name> naming pattern. It's stored in the same namespace as the underlying workload.

  We expect that other security vendors will integrate with Starboard and comply with the ConfigAuditReport schema. The challange with that is that they tend to come up with their own configurations and output formats, even though the modus operandi of such tools is the same.

• KubeHunterReport - it's a cluster scoped resource which represents the outcome of running pen tests against the whole cluster. Currently the data model is inspired (= same) as kube-hunter's output, but we can make it more generic to onboard 3rd party pen testing tools. There's 0 to 1 instances of such report with hardcoded name cluster. It does not have any owner reference set as there's no built-in Kubernetes resource that represents a cluster. For that reason we cannot garbage collect such report automatically as we do for other reports.

• CISKubeBenchReport - it's a cluster scoped resource owned by Kubernetes nodes, which represents results of running CIS Kubernetes Benchmark tests on the given node of your cluster. It's named by the name of the 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.

[bygui86]

@danielpacak thanks for the explanation, it's pretty clear!
I think we can consider this question as answered :)

Looking forward new integrations :) popeye as well would be a really good additional tool!