kube-no-trouble (kubent) Integration with DefectDojo

kube-no-trouble (kubent) Integration with DefectDojo

kube-no-trouble, usually called kubent, is an open source tool from DoiT International, released under the MIT license, that finds Kubernetes objects using deprecated API versions. It collects objects from local manifest files in YAML or JSON, from the last-applied-configuration annotation kubectl leaves on cluster objects, and from Helm v3 releases stored as Secrets or ConfigMaps. kubent compares what it finds against rulesets for upcoming Kubernetes releases, and writes text, JSON, or CSV output.

kube-no-trouble (kubent) Integration with DefectDojo

Kubernetes upgrades fail in boring ways: a Deployment still on extensions/v1beta1, a forgotten Helm release that won't apply after the API is removed. We run kubent before each upgrade and import its JSON into DefectDojo so each deprecated API usage becomes a Finding that a specific team owns. The replacement API is already in the Finding, the upgrade owner can see what is still open at a glance, and reimporting after each round of fixes shows progress without anyone keeping a spreadsheet.

Why kubent Matters

Deprecated APIs are a scheduling problem as much as a technical one. Once a Kubernetes release removes an API, manifests that use it stop applying, and that usually shows up on upgrade day.

• kubent reads several sources at once, including Helm release data, so it finds objects that never appear in a Git repository.
• It names the replacement API, which turns most findings into a mechanical change.
• It can target a specific Kubernetes version, so teams can check against the release they are about to move to.
• It can exit with a non-zero code when it finds issues, which makes it easy to use as a pipeline gate.

Advantages of This Integration

What we gain by sending kubent results to DefectDojo:

• One Finding per object. Every object kubent reports becomes a Finding titled with the deprecated API version and the object's kind and name.
• Migration details in the Finding. The description records the namespace, ruleset, the Kubernetes release the API is removed in (parsed from the ruleset name), the release it was deprecated in, and the replacement API. The mitigation says which API to migrate to.
• Deduplication across runs. The hash uses the vulnerability ID (API version and kind) and the component (kind and name), so running kubent daily doesn't create duplicates.
• Progress tracking. Reimporting into the same Test mitigates objects that were migrated, so the open count drops as teams finish.
• Assignment and ticketing. Findings can be assigned to owning teams and pushed to Jira, which is often how upgrade work gets scheduled.

How This Integration Works

DefectDojo imports kubent output with the kubent Scan scan type.

1. Produce a JSON report. Check manifest files:

kubent -f manifests/ -o json > kubent.json

Or check the cluster your kubeconfig points to against the release you plan to upgrade to:

kubent -t 1.29 -o json > kubent.json

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

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=kubent Scan" 
  -F "file=@kubent.json" 
  -F "product_name=prod-cluster" 
  -F "engagement_name=Kubernetes 1.29 Upgrade" 
  -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 "kubent Scan" 
  --report-path "./kubent.json" 
  --product-name "prod-cluster" 
  --engagement-name "Kubernetes 1.29 Upgrade" 
  --auto-create-context

3. Reimport as teams migrate. Send later reports to /api/v2/reimport-scan/ for the same Test so migrated objects are mitigated.

Data Granularity: What Gets Imported

kubent doesn't say whether an API is only deprecated or already removed, so the parser can't grade them differently. If you need that distinction in severity, DefectDojo's Pluto parser reads Pluto's explicit removed flag.

Use Cases

Before a cluster upgrade: The platform team runs kubent against the cluster with the target version set, imports the report into an Engagement for the upgrade, and assigns each Finding to the team that owns the namespace. Reimporting each week shows the remaining list shrinking.

In a manifest pipeline: Pull requests that change manifests run kubent on the files. A new Finding in the service's Test means someone just added a deprecated API, and it is caught before it reaches a cluster.

For Helm-heavy clusters: Because kubent reads Helm v3 release data, it reports objects from charts installed long ago that nobody has in Git. Those Findings are often the ones that would have broken the upgrade.

Across many clusters: Each cluster is its own Asset. Upgrade owners can compare how many deprecated usages remain per cluster and schedule upgrades starting with the clean ones.

Operational Tips

• Use one Test per cluster. The component name is Kind/name without the namespace, so two objects with the same kind and name in different namespaces hash as the same Finding within a Test. The namespace is still in the description.
• Set the target version with -t to the release you are upgrading to, rather than relying on detection, so the report matches your plan.
• Since every finding is Medium, use the removal release in the description to prioritize. Tag imports with the target release (for example tags=k8s-1.29) to filter them.
• If you need a hard stop in CI, use kubent's exit code option there, and keep DefectDojo for tracking rather than gating.
• Set the SLA for these findings to line up with your upgrade date, or use the Engagement's dates to make the deadline visible.
• Reimport after each upgrade too. Objects that were recreated from an old manifest will come back as reactivated Findings.