KubeEye Integration with DefectDojo

KubeEye Integration with DefectDojo

KubeEye is an open source cluster inspection tool for Kubernetes from the KubeSphere project, released under the Apache 2.0 license. It runs inside the cluster, installed with a Helm chart, and evaluates custom rules such as OPA policies, PromQL queries, file change checks, kernel parameter checks, systemd unit checks, and command output checks. Inspections are defined with InspectPlan and InspectRule resources, and each run produces an InspectResult object in the cluster that can be exported as JSON. KubeEye can also serve HTML reports through its own API server.

KubeEye Integration with DefectDojo

KubeEye looks at the parts of a cluster that manifest scanners never see: kernel settings on the nodes, changed system files, unhealthy control plane components, and alerting rules that fire. We export each completed InspectResult and import it into DefectDojo, which turns every failed inspection into a Finding tied to the node, namespace, or cluster it came from. Node hardening drift then gets an owner and a due date, and the next inspection tells us whether it was fixed.

Why KubeEye Matters

A cluster can pass every manifest check and still be unsafe because of what runs underneath it.

• It inspects nodes directly, covering sysctl values, systemd units, file integrity, and command output that only exist on the host.
• Its rules are custom, so a team can encode its own hardening baseline instead of accepting a fixed rule set.
• It records which rules passed as well as which failed, so a result is a full picture of the inspection.
• Each rule declares a level (danger, warning, or ignore), which gives a usable starting severity.

Advantages of This Integration

What we gain by sending KubeEye results to DefectDojo:

• Only failures are imported. Entries where KubeEye's assert is true (the inspection found the problem) become Findings. Passing checks are skipped.
• Severity from the rule. KubeEye danger maps to High, warning to Medium, and ignore to Info. A missing or unknown level falls back to Medium.
• Readable titles. Each Finding is titled with the inspection kind and the rule name, so a node disk check and a Prometheus rule are easy to tell apart in a list.
• Deduplication per rule and target. The hash uses the rule name and the component (node, namespace, or cluster), so the same rule failing on the same node is one Finding over time.
• History across inspections. Reimporting each new result into the same Test mitigates problems that were fixed and reactivates any that come back.

How This Integration Works

DefectDojo imports KubeEye output with the KubeEye Scan scan type.

1. Export a completed inspection. After an inspection finishes, export its result as JSON:

kubectl get inspectresult <name> -o json > kubeeye.json

A Kubernetes List of several results (for example, from kubectl get inspectresult -o json without a name) is accepted as well as a single result.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select KubeEye Scan, and upload the file. Through the API, available in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=KubeEye Scan" 
  -F "file=@kubeeye.json" 
  -F "product_name=prod-cluster" 
  -F "engagement_name=Cluster Inspection" 
  -F "auto_create_context=true"

DefectDojo Pro users can use Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "KubeEye Scan" 
  --report-path "./kubeeye.json" 
  --product-name "prod-cluster" 
  --engagement-name "Cluster Inspection" 
  --auto-create-context

3. Reimport each inspection. Send later results to /api/v2/reimport-scan/ for the same Test so the cluster's history lives in one place.

The parser reads these sections of the result's spec: node information, file change, file filter, sysctl, systemd, command, component, service connectivity, and Prometheus rule results. Entries in other sections are not imported.

Data Granularity: What Gets Imported

When KubeEye records a list of issues for an entry (such as the lines that changed in a watched file), they are added to the description as a bulleted list.

Use Cases

For node hardening baselines: A platform team encodes its kernel and systemd baseline as KubeEye rules and runs an inspection weekly. Each import shows which nodes drifted, with the node name as the component, and the fix is assigned to whoever owns that node pool.

For file integrity on nodes: File change rules watch sensitive configuration files on each node. When KubeEye reports a change, the Finding carries the path and the captured issues, giving the on-call engineer what they need to decide whether it was expected.

For control plane health: Component and service connectivity results flag unhealthy components or unreachable services. Tracking them in DefectDojo creates a record of how often they occur and how long they take to resolve.

For multi-cluster reporting: Each cluster maps to its own Asset. Security leads can compare High findings by cluster and see which environments are behind on their baseline.

Operational Tips

• Set level on every rule. Rules without a level import as Medium, which may not match how much you care about them.
• Use ignore deliberately. Results at that level import as Info rather than being dropped, so acknowledged issues stay visible without affecting SLA reporting.
• Keep one Test per cluster. Component names are node or namespace names, which can repeat across clusters.
• Be aware that file path isn't part of the hash. If one rule watches several files on the same node, changes to different files count as the same Finding.
• Export results only after the inspection is complete, so a partial result doesn't mitigate findings that simply weren't checked yet.
• Tag imports with the cluster name and inspection plan name so you can filter findings by baseline.